L'administrateur du navigateur /webadmin et Internal Content API sont deux portes d'entrée vers les mêmes données CMS, mais ils n'ont pas été construits en même temps et ne couvrent pas le même terrain. Le panneau constitue la surface opérateur complète. L’API est une surface délibérément plus étroite pour les outils d’IA et d’opérateur fiables.

Ce document fait autorité pour déterminer où les deux sont d'accord, où l'API couvre moins et où l'écart est une limite délibérée plutôt qu'un travail inachevé. Il existe pour que :

• une IA ou un outil opérateur peut découvrir ce qu’il ne peut pas faire avant d’essayer ;
• un réviseur peut distinguer une limite intentionnelle d'un point final manquant ;
• le travail sur la feuille de route a une liste unique sur laquelle se clôturer.

Il s'agit d'un enregistrement de statut, pas d'une spécification. Lorsqu'un point de terminaison est expédié, mettez à jour la ligne ici dans le même commit.

Chaque ligne comporte un statut :

« Panneau uniquement par conception » n'est pas synonyme de « dur ». Cela signifie que l'exclusion est la posture de sécurité décrite dans la section Limites de Internal Content API : pas de publication automatique, pas d'exploration ou de récupération à distance, pas de remplacement d'importation/exportation arbitraire et aucune élévation de privilèges via un jeton.

L'API n'est pas un préfixe unique. Un outil s'intégrant au CMS parle à deux :

La scission est historique plutôt que fondée sur des principes. /admin-api est antérieur au modèle de capacités et ses routes ne vérifiaient rien au-delà de la validité du jeton jusqu'à l'introduction de domains.write et domains.delete : tout jeton valide pouvait ajouter ou supprimer un domaine. Les routes de domaine résident désormais également sous /webadmin/api, c'est là que devraient pointer les nouvelles intégrations ; le préfixe hérité continue de fonctionner pour les outils de provisionnement existants.

Les capacités sont définies dans CmsApiTokenCapabilities. Une lacune dans ce document est parfois autant une capacité manquante qu'un itinéraire manquant.

Les deux qui dominaient cette liste sont fermés.

Identité de page et traductions de page. create_draft_page écrit name, slug et path sur une ligne de traduction de page pour un paramètre régional, et jusqu'à ce que l'API de traduction de page arrive, rien ne peut toucher cette ligne par la suite : les modes de remplacement et de mise à jour par étapes se normalisent page à null et gère uniquement le contenu des emplacements. Une page créée avec le mauvais chemin ne pouvait être corrigée qu'en la supprimant et en la recréant, aucune page ne pouvait obtenir un deuxième paramètre régional et le référencement au niveau de la page - seo_title, seo_description, seo_keywords, og_title, og_description, og_image_media_id, qui se trouvent tous sur cette ligne - était inscriptible et absent de lire également les charges utiles.

/pages/{page}/translations/* couvre désormais tout cela, et comme le titre et le slug Page lisent la traduction par défaut, renommer cette traduction renomme la page. Voir Localization pour savoir pourquoi ces champs appartiennent à la ligne de traduction et Internal Content API pour le contrat d'écriture.

Les valeurs par défaut du référencement au niveau du site sont toujours inaccessibles, pour une raison distincte ; voir les sites ci-dessous.

À partir de la version 1.91.0, huit blocs multimédias natifs exposent également mobile_media_id dans les plans et PATCH, avec la même sélection et le même repli que le panneau. Voir Variantes d'images Media.

Les blocs constituent la zone la mieux alignée du CMS. Les écritures de paramètres sont en outre limitées par BlockSettingsPatchPolicy, qui constitue une protection plutôt qu'un écart.

La suppression nécessite la capacité destructrice shared-slots.delete et refuse de supprimer un Shared Slot de tout emplacement de page encore référencé, répertoriant les emplacements de référence afin qu'un outil puisse les détacher en premier.

POST /media/folders refuse un nom qui existe déjà sous le même parent et renvoie le dossier existant, donc un outil de nouvelle tentative le réutilise au lieu d'accumuler des doublons.

Les messages Contact n’ont aucune représentation API. Un outil peut créer un formulaire de contact via l'API mais ne peut ni lire ses soumissions ni savoir où elles sont livrées — voir Sites.

Le formulaire du site du panel écrit plus de vingt champs. L'API les couvre via des points de terminaison étroits à usage unique : branding, head, timezone, public-theme, seo, contact-recipient et locales.

Ce qui manque ici, c'est l'identité du site (nom, identifiant, indicateur principal) et les variables du site. Ceux-ci sont plus proches du provisionnement que du contenu, et aucun outil n’en a encore eu besoin.

Tout ce qui se trouve dans ce groupe est lisible et rien n'est accessible en écriture.

L'accès au schéma en lecture seule est défendable : les types de blocs et les dispositions sont des contrats structurels, et laisser un jeton les inventer élargit le rayon d'action de chaque écriture de contenu ultérieure. Elle est enregistrée comme partielle plutôt que comme intentionnelle, car aucune décision de ce type n'est écrite nulle part.

Jusqu'à ce que ce problème soit résolu, chaque lacune dans ce document était silencieuse du côté de l'appelant.

POST /content/validate et POST /content/apply ont rejeté une liste fixe de clés interdites (clés de publication et de planification, création de site, récupération à distance et verbes destructeurs) mais rien n'est simplement méconnu. La normalisation du plan a lu les clés qu'elle connaissait et a ignoré le reste, donc un plan portant page.seo_title a renvoyé ok: true et un 201 n'en ayant rien écrit. Un outil a signalé un succès ; il ne s'était rien passé. La lecture de la page ne l'a pas non plus révélé, car les champs que l'API ne peut pas écrire sont également absents de ses charges utiles de lecture.

Les clés non reconnues sont désormais rejetées avec 422 et le code stable unsupported_plan_fields, et le chemin d'erreur nomme chaque champ rejeté. Le jeu de clés accepté est limité au plan mode : replace_slots est significatif lors du remplacement d'une page et rejeté lors de sa création.

Cela ne comble aucun écart ci-dessous. Cela les rend détectables, ce qui est la condition préalable pour qu'un outil puisse revenir au panneau au lieu de signaler une écriture qui n'a jamais eu lieu.

Ordonné par combien chacun débloque, pas par effort.

Niveau 1 — complet

1. Rejectez les clés de plan non reconnues avec 422. Voir Clés de plan inconnues ci-dessus.
2. Point de terminaison d'écriture de traduction de page. /pages/{page}/translations/* écrit le nom, le slug, le chemin, le référencement et l'Open Graph, et les relit.
3. Mise à jour de l'identité de la page. Livré avec 2 : le titre, le slug et le chemin sont des champs de traduction, et la traduction locale par défaut est la propre identité de la page.
4. Shared Slot met à jour et supprime. PATCH et DELETE /shared-slots/{sharedSlot}, ce dernier derrière la nouvelle fonctionnalité shared-slots.delete.

Niveau 2 — complet

1. Extend les paramètres du site : valeurs par défaut SEO, contact_recipient_email, locale_ids. /sites/{site}/seo, /contact-recipient et /locales.
2. Aperçu de page ou instantané de rendu. GET /pages/{page}/render, avec format=html et rendu par paramètres régionaux. Celui-ci avait une mauvaise portée lors de la rédaction de la liste : /webadmin/pages/{page}/preview acceptait déjà un jeton Bearer, donc l'écart résidait dans la découverte et la sélection des paramètres régionaux, pas du tout dans la capacité de rendu.
3. Création du dossier Media. GET/POST /media/folders.
4. Capability-gate les routes de domaine et les déplacez sous /webadmin/api. Terminé, et update et set primary l'accompagnaient.

Ce qui reste

Tout ce qui est encore marqué Manquant ci-dessus est de second ordre : la duplication de pages et les déplacements de sites, les opérations groupées, le convertisseur HTML en bloc, la suppression de commentaires, les messages de contact, la création de schémas, la réindexation de recherche et les rapports de visiteurs. Aucun d’entre eux n’empêche un outil de créer, vérifier, corriger et publier une page, ce qui correspond aux niveaux 1 et 2. Choisissez parmi eux en fonction de la demande plutôt que de parcourir la liste.

Niveau 3 — limites délibérées

Les utilisateurs, l'émission de jetons, les paramètres système, la restauration/téléchargement de sauvegarde, la création et la suppression de sites, le clonage, la promotion et le transfert restent uniquement sur le panneau. Les mises à jour du système sont disponibles via des fonctionnalités API accordées séparément à l'échelle de l'installation à partir de la version 1.90.0. Ils sont répertoriés ici afin que « pas dans l'API » soit une décision enregistrée plutôt qu'une absence non examinée.

À partir de la version 1.92.0, l'installation/mise à jour/activation du panneau et de l'API applique automatiquement les modifications requises de la base de données du plug-in et conserve un état désactivé après un échec. L'activation/la configuration utilise la même porte de compatibilité ; les requêtes incompatibles renvoient HTTP 409 et plugin_incompatible. À partir de la version 1.94.0, la validation de démarrage s'exécute dans un nouveau processus avant l'activation, les mises à jour réussies conservent le package précédent et les échecs de source/route d'exécution mettent le plugin en quarantaine.

Recovery à /webadmin/plugin-recovery est une surface de panneau authentifiée distincte. CMS 1.94.2 nécessite un Super admin actif avec un accès administrateur normal. Il peut désactiver un plugin géré défaillant ou restaurer le package conservé uniquement lorsqu'aucune migration de base de données n'a été exécutée. L'accès par jeton à /plugins/* ne remplace pas cette autorité de récupération du navigateur. Voir Plugin System.