El administrador del navegador en /webadmin y Internal Content API son dos puertas de entrada a los mismos datos de CMS, pero no se crearon al mismo tiempo y no cubren el mismo terreno. El panel es la superficie completa del operador. La API es una superficie deliberadamente más estrecha para herramientas de operador e inteligencia artificial confiables.

Este documento es el mapa autorizado de dónde coinciden los dos, dónde la API cubre menos y dónde la brecha es un límite deliberado en lugar de un trabajo inacabado. Existe de modo que:

• an La IA o la herramienta del operador pueden descubrir lo que no puede hacer antes de intentarlo;
• un revisor puede distinguir un límite intencional de un punto final faltante;
• el trabajo de la hoja de ruta tiene una lista única para cerrar.

Es un registro de estado, no una especificación. Cuando se envíe un punto final, actualice la fila aquí en la misma confirmación.

Cada fila lleva un estado:

"Solo panel por diseño" no es sinónimo de "duro". Significa excluirlo de la postura de seguridad descrita en la sección Límites de Internal Content API: sin publicación automática, sin rastreo o recuperación remota, sin reemplazo arbitrario de importación/exportación y sin escalada de privilegios a través de un token.

La API no es un prefijo único. Una herramienta que se integra con el CMS habla con dos:

La división es histórica más que de principios. /admin-api es anterior al modelo de capacidad y sus rutas no comprobaron nada más allá de la validez del token hasta que se introdujeron domains.write y domains.delete: cualquier token válido podía agregar o eliminar un dominio. Las rutas de dominio ahora también se encuentran bajo /webadmin/api, que es hacia donde deberían apuntar las nuevas integraciones; el prefijo heredado sigue funcionando para las herramientas de aprovisionamiento existentes.

Las capacidades se definen en CmsApiTokenCapabilities. Un vacío en este documento a veces es tanto una capacidad faltante como una ruta faltante.

Los dos que solían dominar esta lista están cerrados.

Identidad de página y traducción de páginas. create_draft_page escribe name, slug y path en una fila de traducción de página para una configuración regional, y hasta que la API de traducción de páginas aterrizó, nada podía tocar esa fila después: los modos de reemplazo y actualización por etapas. normalice page a null y solo maneje el contenido de la ranura. Una página creada en la ruta incorrecta solo se podía arreglar eliminándola y volviéndola a crear, ninguna página podía obtener una segunda ubicación y el SEO a nivel de página (seo_title, seo_description, seo_keywords, og_title, og_description, og_image_media_id, todos los cuales se encuentran en esa fila) no se podía escribir y faltaba. leer también las cargas útiles.

/pages/{page}/translations/* ahora lo cubre todo, y debido a que el título y el slug Page leen la traducción predeterminada, al cambiar el nombre de esa traducción se cambia el nombre de la página. Consulte Localization para saber por qué estos campos pertenecen a la fila de traducción y Internal Content API para el contrato de escritura.

Los valores predeterminados de SEO a nivel de sitio aún son inalcanzables, por otra razón; consulte los sitios a continuación.

Desde 1.91.0, ocho bloques de medios nativos también exponen mobile_media_id en planes y PATCH, con la misma selección y respaldo que el panel. Ver Variantes de imágenes multimedia.

Blocks son el área mejor alineada del CMS. Las escrituras de configuración también están restringidas por BlockSettingsPatchPolicy, que es una protección en lugar de un espacio.

La eliminación requiere la capacidad destructiva shared-slots.delete y se niega a eliminar un Shared Slot de cualquier ranura de página a la que aún se haga referencia, enumerando las ranuras de referencia para que una herramienta pueda separarlas primero.

POST /media/folders rechaza un nombre que ya existe bajo el mismo padre y devuelve la carpeta existente, por lo que una herramienta de reintento lo reutiliza en lugar de acumular duplicados.

Los mensajes de contacto no tienen ninguna representación API. Una herramienta puede crear un formulario de contacto a través de la API, pero no puede leer sus envíos ni saber dónde se entregan; consulte Sites.

El formulario del sitio del panel escribe más de veinte campos. La API los cubre a través de puntos finales estrechos de propósito único: branding, head, timezone, public-theme, seo, contact-recipient y locales.

Lo que falta aquí es la identidad del sitio (nombre, identificador, indicador principal) y las variables del sitio. Están más cerca del aprovisionamiento que del contenido, y ninguna herramienta los ha necesitado todavía.

Todo lo que hay en este grupo se puede leer y nada se puede escribir.

El acceso al esquema de solo lectura es defendible: los tipos y diseños de bloques son contratos estructurales, y permitir que un token los invente amplía el radio de explosión de cada escritura de contenido posterior. Se registra como Parcial en lugar de por diseño porque dicha decisión no está escrita en ninguna parte.

Hasta que esto se solucionó, todos los espacios en este documento estaban en silencio por parte de la persona que llama.

POST /content/validate y POST /content/apply rechazaron una lista fija de claves prohibidas (claves de publicación y programación, creación de sitios, recuperación remota y verbos destructivos), pero nada simplemente no reconocido. La normalización del plan leyó las claves que conocía e ignoró el resto, por lo que un plan que llevaba page.seo_title devolvió ok: true y un 201 no había escrito nada de eso. Una herramienta informó éxito; no había pasado nada. La lectura de la página tampoco lo reveló, porque los campos que la API no puede escribir tampoco están presentes en sus cargas útiles de lectura.

ULas claves no reconocidas ahora se rechazan con 422 y el código estable unsupported_plan_fields, y la ruta de error nombra cada campo rechazado. El conjunto de claves aceptado tiene como ámbito el plan mode: replace_slots es significativo al reemplazar una página y se rechaza al crear una.

Esto no cierra ningún vacío a continuación. Los hace reconocibles, que es el requisito previo para que una herramienta pueda recurrir al panel en lugar de informar una escritura que nunca ocurrió.

Ordenados por cuánto desbloquea cada uno, no por esfuerzo.

Nivel 1: completo

1. Rechace claves de planes no reconocidas con 422. Consulte Claves de planes desconocidos más arriba.
2. Punto final de escritura de traducción de página. /pages/{page}/translations/* escribe el nombre, slug, ruta, SEO y Open Graph, y los vuelve a leer.
3. Actualización de identidad de página. Se entrega con 2: título, slug y ruta son campos de traducción, y la traducción de la configuración regional predeterminada es la propia identidad de la página.
4. Actualización y eliminación de Shared Slot. PATCH y DELETE /shared-slots/{sharedSlot}, este último detrás de la nueva capacidad shared-slots.delete.

Nivel 2: completo

1. Ampliar la configuración del sitio: valores predeterminados de SEO, contact_recipient_email, locale_ids. /sites/{site}/seo, /contact-recipient y /locales.
2. Vista previa de página o instantánea de renderizado. GET /pages/{page}/render, con format=html y renderizado por configuración regional. Este tenía un alcance incorrecto cuando se escribió la lista: /webadmin/pages/{page}/preview ya aceptaba un token de portador, por lo que la brecha era la capacidad de descubrimiento y la selección de ubicación, no la capacidad de renderizar en absoluto.
3. Creación de carpeta multimedia. GET/POST /media/folders.
4. Capability-gate las rutas del dominio y muévalas a /webadmin/api. Listo, y update y set primary vienen con él.

Lo que queda

Todo lo que todavía está marcado como Faltante arriba es de segundo orden: duplicación de páginas y movimientos de sitios, operaciones masivas, el convertidor de bloque a HTML, eliminación de comentarios, mensajes de contacto, creación de esquemas, reindexación de búsqueda e informes de visitantes. Ninguno de ellos impide que una herramienta cree, verifique, corrija y publique una página, que es de lo que se trataban los Niveles 1 y 2. Elija entre ellos según la demanda en lugar de seguir la lista.

Nivel 3: límites deliberados

Usuarios, emisión de tokens, configuración del sistema, restauración/descarga de copias de seguridad, creación y eliminación de sitios, clonación, promoción y transferencia solo en el panel Stay. Las actualizaciones del sistema están disponibles a través de capacidades API para toda la instalación otorgadas por separado desde 1.90.0. Se enumeran aquí para que "no en la API" sea una decisión registrada en lugar de una ausencia no examinada.

Desde 1.92.0, la instalación/actualización/activación del panel y API aplican los cambios requeridos en la base de datos del complemento automáticamente y mantienen un estado deshabilitado después de una falla. Habilitar/configurar utiliza la misma puerta de compatibilidad; Las solicitudes incompatibles devuelven HTTP 409 y plugin_incompatible. A partir de la versión 1.94.0, la validación de inicio se ejecuta en un proceso nuevo antes de la activación, las actualizaciones exitosas conservan el paquete anterior y las fallas de ruta/fuente de tiempo de ejecución ponen en cuarentena el complemento.

La recuperación en /webadmin/plugin-recovery es una superficie de panel autenticada separada. CMS 1.94.2 requiere un Super admin activo con acceso de administrador normal. Puede deshabilitar un complemento administrado defectuoso o restaurar el paquete retenido solo cuando no se ejecutó ninguna migración de base de datos. El acceso token a /plugins/* no reemplaza esta autoridad de recuperación del navegador. Ver Sistema de complementos.