Internal Content API

Propósito

La Internal Content API es una API segura del CMS para herramientas de IA y de operador de confianza. Permite que esas herramientas inspeccionen los contratos de contenido del CMS, creen contenido en borrador desde el principio, sustituyan slots concretos propiedad de la página en páginas en borrador existentes y ejecuten operaciones de publicación explícitas mediante JSON estructurado, sin iniciar sesión en la interfaz de administración del navegador, extraer datos de ella ni automatizarla.

La fase 1 está implementada como una API no pública, protegida por token y exclusivamente JSON, para el descubrimiento de contenido en modo de solo lectura más la creación de páginas en borrador mediante planes de contenido validados. La fase 2A añade bases seguras para los menús de navegación, los Shared Slots y la asignación explícita de Shared Slots a slots de página. La fase 2B añade la sustitución controlada, solo en borrador, del contenido de slots propiedad de la página en páginas existentes. Los endpoints de publicación son explícitos y requieren content.publish; content apply sigue siendo borrador primero y no publica. La API se mantiene intencionadamente estrecha: sin descarga remota, sin eliminación amplia de páginas a través de content apply, sin sustitución de slots respaldados por Shared Slots y sin publicación en cascada de Shared Slots.

Posicionamiento del producto

La Internal Content API es:

una API del CMS interna/para operadores
protegida por token
no pública
no una API de entrega de CMS headless
no un sustituto de los permisos de administración
no un sustituto de la importación/exportación
no una integración con un proveedor de IA

El núcleo del CMS debe ser el propietario de esta API porque opera sobre conceptos de contenido del núcleo: sitios, páginas, layouts, slots, bloques, traducciones, navegación y shared slots. Las herramientas de IA o de operador pueden llamar a la API, pero el núcleo del CMS no debe incorporar lógica de integración de OpenAI, LLM, rastreadores ni proveedores concretos.

Prefijo de ruta

El prefijo canónico es:

/webadmin/api

Así la API permanece dentro del límite de administración del CMS mientras usa un segmento de API conciso y familiar. Los endpoints de estilo recurso deben situarse directamente bajo este prefijo, como /webadmin/api/pages y /webadmin/api/blocks.

El descubrimiento de la API comienza en:

GET /webadmin/api

Quienes llamen sin autenticarse reciben únicamente el JSON de arranque seguro para el público. Quienes llamen autenticados reciben metadatos seguros de versión del producto más enlaces a OpenAPI, la guía de IA, el contrato de contenido, los ejemplos, content validate/apply, las páginas, la navegación y los Shared Slots. Las herramientas externas de IA/operador deben partir de esta respuesta de descubrimiento en vivo en lugar de leer el repositorio del CMS o la documentación local del paquete.

Las operaciones de contenido basadas en planes usan:

POST /webadmin/api/content/validate
POST /webadmin/api/content/apply

Opciones de ruta que conviene evitar:

/webadmin/internal-api, porque es innecesariamente verboso
/webadmin/api/content-plans/..., porque content-plans es demasiado técnico y limitado para el contrato de la URL
colocar todos los recursos bajo /webadmin/api/content/..., porque las API de recursos deben mantenerse claras y directas
/admin, porque el CMS no debe dar por supuesto que la ruta /admin del producto anfitrión le pertenece
/cms, porque /cms sigue reservado únicamente para los recursos estáticos del CMS

Autenticación

La API utiliza autenticación con token Bearer:

Authorization: Bearer <token>

Los tokens de la API del CMS los crea un super administrador del CMS desde System -> API Tokens. El CMS almacena únicamente un hash SHA-256 más una vista previa segura en la tabla de base de datos cms_api_tokens. El token en texto plano se muestra una sola vez, inmediatamente después de crearlo, y nunca vuelve a mostrarse.

Los super administradores pueden revocar un token para desactivar de inmediato el acceso a la API manteniendo visible la fila de auditoría, o eliminar un token para borrar permanentemente su registro de la lista. Eliminar un token activo también desactiva de inmediato el acceso a la API, porque el autenticador ya no puede encontrar un hash almacenado que coincida.

Las herramientas locales de IA y de operador deben guardar el token generado en un almacén de secretos de operador de confianza.

Utilice la URL base de la Internal Content API en la configuración local del operador:

WEBBLOCKS_CMS_API_URL=https://example.com/webadmin/api
WEBBLOCKS_CMS_API_TOKEN=...

El entorno de ejecución del CMS no requiere WEBBLOCKS_CMS_INTERNAL_API_TOKEN.

Reglas de autenticación:

los tokens ausentes, incorrectos o revocados devuelven un 401 en JSON
los tokens revocados dejan de funcionar de inmediato
los tokens nunca deben imprimirse en registros, diagnósticos, informes de soporte, pruebas ni ejemplos de documentación
la comparación de tokens debe usar una comparación de tiempo constante
las peticiones correctas a la API actualizan last_used_at y last_used_ip del token
las peticiones correctas a la API también guardan un user-agent truncado como contexto de auditoría para el operador
las respuestas son exclusivamente JSON

Ejemplo de petición:

GET /webadmin/api/sites
Authorization: Bearer <token>
Accept: application/json
Content-Type: application/json

Capacidades

Los super administradores eligen las capacidades del token al crearlo desde System -> API Tokens, y más adelante pueden editar el nombre y las capacidades de un token sin exponer ni rotar su secreto. El descubrimiento expone las capacidades guardadas sin devolver el valor del token, su hash ni su vista previa. Los tokens estándar para construir páginas tienen por defecto estas capacidades:

content.read
content.validate
content.apply
navigation.write
shared-slots.write

Las capacidades destructivas y de publicación son opciones avanzadas independientes y no se seleccionan por defecto:

content.publish
pages.delete

Los endpoints de escritura comprueban la capacidad correspondiente en el servidor. Las capacidades ausentes devuelven un 403 en JSON con indicaciones en api_discovery_url, openapi_url, documentation_url y example_url. Los tokens normales para construir páginas no deben incluir capacidades destructivas.

Modelo de la API

La API tiene dos modos complementarios.

Resource API

Los endpoints de recurso reflejan operaciones equivalentes a las de administración, una por una:

listar y leer páginas
listar y leer bloques
listar sitios, idiomas (locales), layouts y tipos de bloque
más adelante, crear o actualizar directamente recursos de página en borrador
más adelante, listar o garantizar los slots de página
más adelante, añadir, actualizar, mover y eliminar bloques mediante endpoints de recurso
más adelante, añadir bloques hijos mediante endpoints de recurso
más adelante, gestionar la navegación y los shared slots

Endpoints de recurso de la fase 1:

GET /webadmin/api/sites
GET /webadmin/api/locales
GET /webadmin/api/page-layouts
GET /webadmin/api/block-types
GET /webadmin/api/content-contract
GET /webadmin/api/pages
GET /webadmin/api/pages/{page}
POST /webadmin/api/pages/{page}/publish
POST /webadmin/api/pages/{page}/publish-page-owned-blocks
POST /webadmin/api/pages/{page}/slots/{slot}/shared-slot
GET /webadmin/api/blocks
GET /webadmin/api/blocks/{block}
GET /webadmin/api/navigation-menus
GET /webadmin/api/navigation-menus/{navigationMenu}
POST /webadmin/api/navigation-menus
POST /webadmin/api/navigation-menus/{navigationMenu}/items
GET /webadmin/api/shared-slots
GET /webadmin/api/shared-slots/{sharedSlot}
POST /webadmin/api/shared-slots
POST /webadmin/api/shared-slots/{sharedSlot}/blocks

Content Validate / Apply API

Los endpoints de content validate/apply gestionan planes de contenido completos de varios pasos:

POST /webadmin/api/content/validate
POST /webadmin/api/content/apply

validate comprueba un plan de contenido completo y no escribe nada. apply vuelve a validar el plan y después crea de forma transaccional la página en borrador solicitada, los elementos de navegación, los Shared Slots, los árboles de bloques de Shared Slot y las asignaciones de Shared Slot a slots de página. También puede sustituir slots concretos propiedad de la página en una página en borrador existente cuando el plan usa mode: replace_existing_draft_page e incluye una salvaguarda optimista. Esto resulta útil para páginas generadas por IA, plantillas, páginas de inicio rápido, cabeceras/pies compartidos y utilidades de migración, casos en los que el CMS debe evitar contenido creado a medias.

El cuerpo de la petición puede seguir conteniendo un campo plan u otro payload estructurado de plan de contenido. La URL debe seguir siendo /content/validate y /content/apply.

Ambos modos son necesarios:

la Resource API expone el modelo de contenido y los contratos existentes del CMS a las herramientas internas
la Content Validate / Apply API evita escrituras parciales durante construcciones de página más grandes

Sustitución de slots en páginas en borrador existentes

La sustitución en páginas en borrador existentes se mantiene dentro del contrato de validate/apply:

POST /webadmin/api/content/validate
POST /webadmin/api/content/apply

Use mode: replace_existing_draft_page para sustituir uno o varios slots propiedad de la página en una página en borrador existente. La operación requiere content.validate para validar y content.apply para aplicar. No requiere pages.delete, porque no es una operación general de eliminación de páginas.

El path de Page Translation es la URL pública canónica. Los planes nuevos deben usar rutas como /contact, /features o /docs/internal-content-api; /p/... es únicamente compatibilidad heredada. Las rutas con barras se normalizan segmento a segmento, de modo que /docs/internal-content-api/ pasa a ser /docs/internal-content-api y no se colapsa en docsinternal-content-api. Las áreas de ruta reservadas como /webadmin, /webadmin/api, /cms, /search, /search.json, /contact-messages, /install y las rutas de autenticación del anfitrión no pueden crearse como rutas públicas de página.

Ejemplo:

{
  "plan": {
    "mode": "replace_existing_draft_page",
    "site": "default",
    "locale": "en",
    "page": {
      "id": 9,
      "expected_path": "/contact",
      "status": "draft"
    },
    "replace_slots": {
      "main": [
        {
          "type": "plain_text",
          "translations": {
            "content": "Updated draft contact content."
          }
        }
      ]
    }
  }
}

Reglas:

la página de destino debe estar en estado draft
se requiere expected_path o expected_updated_at
expected_path usa la ruta pública canónica de Page Translation, no un alias heredado /p/...
la página de destino debe pertenecer al sitio solicitado y el idioma (locale) debe estar habilitado para ese sitio
cada slot debe existir en la página y usar bloques propiedad de la página
los slots respaldados por Shared Slots se rechazan en lugar de vaciarse
solo se eliminan los bloques de los replace_slots indicados
los bloques antiguos se eliminan y los nuevos se escriben en una sola transacción
se capturan revisiones de la página antes y después de aplicar
no se produce publicación, descarga/importación de medios, eliminación amplia ni vaciado de asignaciones de Shared Slot

Metadatos de sincronización de origen

Los planes de contenido pueden guardar un objeto source_sync limitado y libre de secretos para los flujos de sincronización de documentación de IA/operador. Los ajustes de página arbitrarios se rechazan. La forma aceptada es:

{
  "page": {
    "settings": {
      "source_sync": {
        "type": "markdown_documentation",
        "source_id": "webblocks-cms:docs/internal-content-api.md",
        "source_path": "docs/internal-content-api.md",
        "source_sha256": "64-character-lowercase-sha256",
        "managed_slots": ["main"],
        "last_synced_at": "2026-06-25T00:00:00Z"
      }
    }
  }
}

Apply guarda estos metadatos en los ajustes de la página, y las respuestas de la API de listado/detalle de páginas exponen los mismos campos permitidos de source_sync para futuras coincidencias. No incluya tokens, valores de entorno, rutas absolutas locales o del servidor ni otros secretos.

Endpoints de publicación explícitos

La publicación está separada de content apply y requiere un token con content.publish.

POST /webadmin/api/pages/{page}/publish
POST /webadmin/api/pages/{page}/publish-page-owned-blocks

POST /webadmin/api/pages/{page}/publish publica el registro de la página. Su payload por defecto afecta solo a la página:

{
  "include_page_owned_blocks": false
}

Reglas:

omitir include_page_owned_blocks equivale a false
include_page_owned_blocks: false publica solo el registro de la página y deja sin cambios los bloques en borrador o en revisión
include_page_owned_blocks: true publica los bloques en borrador y en revisión que pertenecen a los slots de página no compartidos, incluidos los bloques hijos anidados
los bloques ya publicados permanecen sin cambios
los slots respaldados por Shared Slots quedan excluidos y se informan en la respuesta
los campos de cascada de Shared Slot no admitidos, como publish_shared_slots, include_shared_slot_blocks o shared_slot_cascade, devuelven un 422 en JSON
la respuesta incluye los metadatos de id/estado/ruta de la página, si se incluyeron los bloques propiedad de la página, el número de bloques publicados, los resúmenes de los Shared Slots excluidos y el id de la revisión de página

POST /webadmin/api/pages/{page}/publish-page-owned-blocks publica únicamente los bloques propiedad de la página sin publicar y no cambia el estado del flujo de trabajo de la página. Usa la misma capacidad content.publish y la misma regla de exclusión de Shared Slots.

Las herramientas de IA/operador no deben suponer que publicar la página hace público todo el contenido de los bloques. Use include_page_owned_blocks: true solo cuando el usuario haya aprobado expresamente publicar todos los bloques sin publicar que pertenecen a esa página. El contenido de los Shared Slots debe revisarse y publicarse por separado.

Endpoint del contrato de contenido

GET /webadmin/api/content-contract es un endpoint de descubrimiento de solo lectura para herramientas de IA/operador de confianza. Devuelve el prefijo de la API, las URL de validate/apply, la plantilla de URL de vista previa de administración, los indicadores de seguridad, las URL de descubrimiento, los patrones recomendados para construir páginas y los metadatos depurados de los contratos de bloque.

El endpoint es un comportamiento genérico del producto CMS. No debe devolver secretos específicos de la instalación, valores de token, contenidos Blade en bruto, rutas absolutas del sistema de archivos, rutas privadas del servidor ni instrucciones específicas de un sitio. Las filas del contrato de bloque pueden incluir handle/slug, etiqueta, categoría, estado, soporte de contenedor e hijos, campos traducibles, campos de ajustes compartidos y el comportamiento raíz del renderizador público.

Las herramientas de IA deben llamar a este endpoint o a GET /webadmin/api/block-types antes de construir un plan y deben usar únicamente handles presentes en la instalación actual.

El contrato de contact_form incluye metadatos de formulario adicionales y seguros: el esquema de ajustes, los campos traducidos, el endpoint público de envío POST /contact-messages, el comportamiento CSRF requerido en el navegador, las reglas de validación del servidor, el campo de comprobación antispam oculto y generado por el CMS, el comportamiento genérico de éxito de ese campo de comprobación, las notas de clasificación/cuarentena de spam, el comportamiento de almacenamiento antes de la notificación, el orden de destinatarios de respaldo, el registro seguro de fallos de notificación y el comportamiento de revisión de /webadmin/contact-messages. El campo de comprobación lo genera el renderizador, no forma parte de la entrada normal del visitante y no deben crearlo manualmente ni la API ni las herramientas de IA/operador. Las herramientas para páginas de contacto deben usar ese bloque nativo en lugar de Trusted HTML, marcado de formulario en bruto o formularios mailto:. El antiguo campo website ya no forma parte del contrato público del Contact Form.

La guía legible por humanos AI Page Building Guide se distribuye en las instalaciones nativas por paquete en vendor/fklavyenet/webblocks-cms/docs/ai-page-building-guide.md.

Alcance de la fase 1

Endpoints de descubrimiento

GET /webadmin/api
GET /webadmin/api/openapi.json
GET /webadmin/api/ai-guide
GET /webadmin/api/examples
GET /webadmin/api/examples/contact-page
GET /webadmin/api/examples/landing-page
GET /webadmin/api/sites
GET /webadmin/api/locales
GET /webadmin/api/page-layouts
GET /webadmin/api/block-types
GET /webadmin/api/content-contract

Endpoints de páginas

GET /webadmin/api/pages
GET /webadmin/api/pages/{page}
POST /webadmin/api/pages/{page}/slots/{slot}/shared-slot

Endpoints de bloques

GET /webadmin/api/blocks
GET /webadmin/api/blocks/{block}

Endpoints de navegación

GET /webadmin/api/navigation-menus
GET /webadmin/api/navigation-menus/{navigationMenu}
POST /webadmin/api/navigation-menus
POST /webadmin/api/navigation-menus/{navigationMenu}/items

Los menús de navegación usan el modelo existente del CMS navigation_items.menu_key. La fase 2A admite los handles de menú que incluye el CMS, como primary, footer, mobile, legal y docs; no añade una tabla de menús aparte. Crear un menú de navegación se trata como crear un grupo de menú seguro con ámbito de sitio y elementos iniciales opcionales. Se niega a sobrescribir un sitio/menú que ya tiene elementos.

Las URL de los elementos de navegación pueden ser rutas internas como /, /about y /contact, o URL seguras http/https. La API rechaza javascript:, data:, las URL relativas al protocolo, el recorrido de directorios, las URL malformadas, los destinos no admitidos y las etiquetas vacías. Los endpoints de navegación no crean páginas, no publican páginas, no rastrean sitios ni descargan URL remotas.

Endpoints de Shared Slots

GET /webadmin/api/shared-slots
GET /webadmin/api/shared-slots/{sharedSlot}
POST /webadmin/api/shared-slots
POST /webadmin/api/shared-slots/{sharedSlot}/blocks

La creación de Shared Slots tiene ámbito de sitio y rechaza handles duplicados dentro del mismo sitio. Los bloques de Shared Slot reutilizan el mismo escritor de payload de bloque que emplean los bloques propiedad de la página, por lo que el texto propio de cada idioma permanece en las filas de traducción y los ajustes compartidos siguen en el registro del bloque / la ruta de ajustes. La importación y la asignación de medios quedan fuera de esta fase.

Asignación de slots de página

POST /webadmin/api/pages/{page}/slots/{slot}/shared-slot

El endpoint asigna un Shared Slot activo, compatible y del mismo sitio ya existente a un slot de página existente. No crea páginas ni slots que falten. No publica la página. Rechaza los Shared Slots de otros sitios, inactivos o incompatibles. También se niega a cambiar un slot que todavía contiene bloques propiedad de la página, porque la fase 2A no elimina ni sustituye esos bloques automáticamente.

Endpoints de Content Validate / Apply

POST /webadmin/api/content/validate
POST /webadmin/api/content/apply

Seguridad de la fase 1

solo borradores
sin publicación a través de content apply
sin sobrescritura de contenido publicado existente
sin sobrescritura amplia de páginas o bloques existentes fuera de mode: replace_existing_draft_page
sin descarga remota
sin descarga ni importación de medios
todavía sin creación de sitios
sin eliminación destructiva de páginas a través de content apply
sin eliminación destructiva de bloques fuera de la sustitución de slots de borrador con ámbito de transacción
todavía sin endpoints de actualización, movimiento o eliminación de recursos
sin requisito de sesión de navegador, formulario o CSRF para las escrituras JSON con token Bearer
el acceso público sin autenticar se limita a la respuesta mínima de arranque de GET /webadmin/api

Forma de los errores JSON

Los errores de la API son exclusivamente JSON. No deben redirigir al inicio de sesión, mostrar páginas de CSRF ni exponer trazas de pila. Campos habituales:

{
  "ok": false,
  "code": "invalid_internal_api_token",
  "message": "Invalid internal API token.",
  "api_discovery_url": "/webadmin/api",
  "openapi_url": "/webadmin/api/openapi.json",
  "documentation_url": "/webadmin/api/ai-guide",
  "example_url": "/webadmin/api/examples/contact-page",
  "errors": []
}

Estados esperados:

401 para tokens ausentes, no válidos o revocados
403 para capacidades ausentes
422 para errores de validación

Ejemplos de la Resource API

Listar páginas

GET /webadmin/api/pages

Leer los detalles de una página

GET /webadmin/api/pages/{page}

Listar bloques

GET /webadmin/api/blocks

Leer los detalles de un bloque

GET /webadmin/api/blocks/{block}

Ejemplo de Content Validate / Apply

El mismo payload puede enviarse a cualquiera de los dos endpoints:

POST /webadmin/api/content/validate
POST /webadmin/api/content/apply

Ejemplo de borrador de página de inicio de marketing en inglés:

{
  "plan": {
    "site": "example-site",
    "locale": "en",
    "layout": "default",
    "page": {
      "title": "Acme Studio",
      "path": "/",
      "status": "draft"
    },
    "slots": {
      "main": [
        {
          "type": "hero",
          "translations": {
            "title": "Plan, build, and publish with confidence",
            "subtitle": "Structured content for modern teams",
            "content": "Create a draft homepage from a validated content plan."
          },
          "children": [
            {
              "type": "button_link",
              "translations": {
                "title": "Start planning"
              },
              "settings": {
                "url": "/contact",
                "variant": "primary"
              }
            }
          ]
        },
        {
          "type": "section",
          "children": [
            {
              "type": "container",
              "children": [
                {
                  "type": "grid",
                  "settings": {
                    "columns": 3
                  },
                  "children": [
                    {
                      "type": "card",
                      "children": [
                        {
                          "type": "card_body",
                          "children": [
                            {
                              "type": "plain_text",
                              "translations": {
                                "content": "Validate the whole draft before anything is written."
                              }
                            }
                          ]
                        }
                      ]
                    }
                  ]
                }
              ]
            }
          ]
        },
        {
          "type": "cta",
          "translations": {
            "title": "Ready to shape the next page?",
            "content": "Use structured plans for repeatable content creation."
          },
          "children": [
            {
              "type": "button_link",
              "translations": {
                "title": "Contact us"
              },
              "settings": {
                "url": "/contact",
                "variant": "primary"
              }
            }
          ]
        }
      ]
    }
  }
}

Reglas de validación

el handle o el ID del sitio debe resolverse
el idioma (locale) debe existir y estar habilitado para el sitio de destino
el layout debe existir
un conflicto de ruta impide la creación de la página
el tipo de bloque debe estar publicado y ser utilizable
el soporte de hijos debe seguir los contratos de bloque cuando estén disponibles
el texto visible para el usuario pertenece a las filas de traducción
los ajustes compartidos siguen siendo compartidos
los ajustes desconocidos no seguros se rechazan
los ajustes desconocidos inocuos pueden generar un aviso o ignorarse de forma coherente
apply vuelve a validar antes de escribir
apply es transaccional
Content apply sigue rechazando las operaciones de publicación, creación de sitios, importación de medios, descarga remota, sobrescritura no admitida, sustitución no admitida y eliminación
la creación de navegación y de Shared Slots es solo de creación, salvo que una fase posterior añada contratos de mutación explícitos y seguros para borradores

Forma de la respuesta

Las respuestas deben ser JSON predecible:

{
  "ok": true,
  "writes": [],
  "data": {
    "page": {
      "id": 123,
      "title": "Product Overview",
      "status": "draft",
      "edit_url": "/webadmin/pages/123/edit"
    }
  },
  "normalized_plan": {},
  "warnings": [],
  "errors": []
}

Los errores de validación deben incluir una ruta y un mensaje:

{
  "ok": false,
  "writes": [],
  "data": null,
  "normalized_plan": {},
  "warnings": [
    {
      "path": "plan.slots.main.1.settings.theme",
      "message": "Unknown harmless setting ignored."
    }
  ],
  "errors": [
    {
      "path": "plan.page.path",
      "message": "A page already exists at this path for the selected site and locale."
    }
  ]
}

Incluya edit_url cuando resulte útil para los recursos del CMS creados o actualizados.

Secciones del plan de la fase 2A

Los planes de contenido pueden incluir navigation_menus, shared_slots y page_slot_shared_slots junto al plan de páginas/slots ya existente. validate no escribe nada. apply escribe todas las secciones válidas en una sola transacción y revierte el plan completo cuando falla cualquier sección posterior.

{
  "plan": {
    "site": "default",
    "locale": "en",
    "layout": "default",
    "page": {
      "title": "Homepage Draft",
      "path": "/",
      "status": "draft"
    },
    "slots": {
      "main": []
    },
    "navigation_menus": [
      {
        "handle": "primary",
        "label": "Primary Navigation",
        "items": [
          {
            "label": "Home",
            "url": "/",
            "target": "_self",
            "sort_order": 10
          }
        ]
      }
    ],
    "shared_slots": [
      {
        "handle": "site-header",
        "label": "Site Header",
        "slot": "header",
        "blocks": []
      }
    ],
    "page_slot_shared_slots": [
      {
        "page": "created",
        "slot": "header",
        "shared_slot": "site-header"
      }
    ]
  }
}

page_slot_shared_slots[].page puede referirse a la página creada por el mismo plan mediante created, o al ID de una página existente. shared_slot puede referirse a un Shared Slot creado antes dentro del mismo plan o al handle de un Shared Slot existente del mismo sitio.

Fases futuras

Fase 2B

endpoints opcionales de actualización/movimiento seguros para borradores destinados a la navegación y a los bloques de Shared Slot
contratos explícitos de vaciado/sustitución seguros donde sea necesario
ayudas más profundas para construir cabeceras/navbars, solo si siguen siendo comportamiento genérico del CMS

Fase 3

endpoints de recursos para ediciones directas de páginas/bloques seguras para borradores donde sea necesario
actualizaciones controladas de borradores o sustitución del contenido en borrador
recursos de página
medios únicamente por ID de medio existente

Fase 4

transiciones de flujo de trabajo explícitas adicionales más allá de la publicación, cuando tengan su propio diseño y permisos

Recomendaciones de uso con IA

descubra primero los sitios, los idiomas (locales), los layouts y los tipos de bloque
valide antes de aplicar
cree contenido en borrador
prefiera los bloques estructurados de docs/public-block-render-markup.md
evite Safe HTML salvo como alternativa revisada
mantenga el texto público generado en el idioma de destino, por ejemplo inglés para una página de inicio en inglés

Límites

sin integración de OpenAI ni de LLM en el núcleo del CMS
sin rastreo ni descarga de contenidos
sin sustitución arbitraria de la importación/exportación
sin publicación automática
sin eliminación destructiva en la fase 1
sin suponer la ruta /admin del host
sin uso del prefijo de ruta /cms
sin código de ejecución específico de QuizTem; la generación de la página de inicio de QuizTem es un caso de uso posterior de esta API genérica del CMS