L'amministratore del browser in /webadmin e Internal Content API sono due porte d'ingresso sugli stessi dati CMS, ma non sono stati creati contemporaneamente e non coprono lo stesso terreno. Il pannello costituisce la superficie operatore completa. L'API è una superficie volutamente più ristretta per strumenti operatore e IA affidabili.

Questo documento è la mappa autorevole di dove i due concordano, dove l'API copre meno e dove il divario è un confine deliberato piuttosto che un lavoro incompiuto. Esiste così che:

• uno strumento AI o operatore può scoprire cosa non può fare prima di provare;
• un revisore può distinguere un confine intenzionale da un punto finale mancante;
• Il lavoro della roadmap ha un unico elenco da chiudere.

È un record di stato, non una specifica. Quando un endpoint viene spedito, aggiorna la riga qui nello stesso commit.

Ogni riga porta uno stato:

"Panel-only by design" non è sinonimo di "hard". Significa escludere che si tratti della strategia di sicurezza descritta nella sezione Confini di Internal Content API: nessuna pubblicazione automatica, nessuna scansione o recupero remoto, nessuna sostituzione arbitraria di importazione/esportazione e nessuna escalation di privilegi tramite un token.

L'API non è un singolo prefisso. Uno strumento che si integra con il CMS parla con due:

La scissione è storica piuttosto che di principio. /admin-api è antecedente al modello di capacità e i suoi percorsi non controllavano nulla oltre alla validità del token fino all'introduzione di domains.write e domains.delete: qualsiasi token valido poteva aggiungere o rimuovere un dominio. I percorsi del dominio ora risiedono anche sotto /webadmin/api, che è dove dovrebbero puntare le nuove integrazioni; il prefisso legacy continua a funzionare per gli strumenti di provisioning esistenti.

Le funzionalità sono definite in CmsApiTokenCapabilities. Una lacuna in questo documento a volte è una capacità mancante tanto quanto un percorso mancante.

I due che dominavano questo elenco sono chiusi.

Identità della pagina e traduzioni della pagina. create_draft_page scrive name, slug e path su una riga di traduzione della pagina per una lingua e fino a quando l'API di traduzione della pagina non è arrivata, nulla potrebbe toccare quella riga in seguito: la sostituzione e Le modalità di aggiornamento graduale normalizzano page in null e gestiscono solo il contenuto dello slot. Una pagina creata nel percorso sbagliato poteva essere corretta solo eliminandola e ricreandola, nessuna pagina poteva ottenere una seconda localizzazione e il SEO a livello di pagina - seo_title, seo_description, seo_keywords, og_title, og_description, og_image_media_id, che vivono tutti su quella riga - era non scrivibile e mancante anche dai payload di lettura.

/pages/{page}/translations/* ora copre tutto e poiché il titolo e lo slug Page leggono la traduzione predefinita, rinominare quella traduzione rinomina la pagina. Vedere Localizzazione per il motivo per cui questi campi appartengono alla riga di traduzione e Internal Content API per il contratto di scrittura.

Le impostazioni predefinite SEO a livello di sito sono ancora irraggiungibili, per un motivo separato; vedere Siti di seguito.

Dalla versione 1.91.0, otto blocchi multimediali nativi espongono anche mobile_media_id nei piani e PATCH, con la stessa selezione e fallback del pannello. Vedi Varianti immagine multimediale.

I blocchi sono l'area meglio allineata del CMS. Le scritture delle impostazioni sono inoltre limitate da BlockSettingsPatchPolicy, che è una protezione anziché un gap.

L'eliminazione richiede la funzionalità distruttiva shared-slots.delete e rifiuta di rimuovere un Shared Slot a cui fa ancora riferimento qualsiasi slot di pagina, elencando gli slot di riferimento in modo che uno strumento possa staccarli prima.

POST /media/folders rifiuta un nome che già esiste sotto lo stesso genitore e restituisce la cartella esistente, quindi uno strumento di ripetizione la riutilizza invece di accumulare duplicati.

Contact non hanno alcuna rappresentazione API. Uno strumento può creare un modulo di contatto tramite l'API ma non può né leggerne gli invii né sapere dove vengono consegnati: vedere Sites.

Il modulo del sito del pannello scrive più di venti campi. L'API li copre tramite endpoint ristretti a scopo singolo: branding, head, timezone, public-theme, seo, contact-recipient e locales.

Ciò che manca qui è l'identità del sito (nome, handle, flag primario) e le variabili del sito. Questi sono più vicini al provisioning che al contenuto e nessuno strumento ne ha ancora avuto bisogno.

Tutto in questo gruppo è leggibile e niente è scrivibile.

L'accesso allo schema di sola lettura è difendibile: i tipi di blocco e i layout sono contratti strutturali e lasciare che sia un token a inventarli amplia il raggio d'azione di ogni successiva scrittura di contenuto. Viene registrata come parziale anziché in base alla progettazione perché tale decisione non è scritta da nessuna parte.

Fino a quando il problema non è stato risolto, ogni lacuna in questo documento era silenziosa dal lato del chiamante.

POST /content/validate e POST /content/apply hanno rifiutato un elenco fisso di chiavi proibite (chiavi di pubblicazione e pianificazione, creazione di siti, recupero remoto e verbi distruttivi) ma nulla semplicemente non riconosciuto. La normalizzazione del piano ha letto le chiavi che conosceva e ha ignorato il resto, quindi un piano che trasportava page.seo_title ha restituito ok: true e uno 201 non avendo scritto nulla di ciò. Uno strumento ha riportato il successo; non era successo niente. Anche la lettura della pagina non lo ha rivelato, perché anche i campi che l'API non può scrivere sono assenti dai suoi payload di lettura.

Le chiavi non riconosciute vengono ora rifiutate con 422 e il codice stabile unsupported_plan_fields e il percorso di errore nomina ciascun campo rifiutato. Il set di chiavi accettato rientra nell'ambito del piano mode: replace_slots è significativo durante la sostituzione di una pagina e rifiutato durante la creazione di una.

Questo non chiude alcuno spazio vuoto sottostante. Li rende rilevabili, che è il prerequisito affinché uno strumento possa ricorrere al pannello invece di segnalare una scrittura mai avvenuta.

Ordinato in base a quanto ciascuno sblocca, non in base allo sforzo.

Livello 1 — completo

1. Rifiutare le chiavi del piano non riconosciute con 422. Vedere Chiavi del piano sconosciute sopra.
2. Endpoint di scrittura della traduzione della pagina. /pages/{page}/translations/* scrive nome, slug, percorso, SEO e Open Graph e li rilegge.
3. Aggiornamento identità pagina. Fornito con 2: titolo, slug e percorso sono campi di traduzione e la traduzione locale predefinita è l'identità della pagina.
4. Shared Slot aggiorna ed elimina. PATCH e DELETE /shared-slots/{sharedSlot}, quest'ultimo dietro la nuova funzionalità shared-slots.delete.

Livello 2 — completo

1. Estendi le impostazioni del sito: impostazioni predefinite SEO, contact_recipient_email, locale_ids. /sites/{site}/seo, /contact-recipient e /locales.
2. Anteprima della pagina o istantanea del rendering. GET /pages/{page}/render, con format=html e rendering per locale. Questo aveva un ambito errato quando è stato scritto l'elenco: /webadmin/pages/{page}/preview accettava già un token Bearer, quindi il divario era la rilevabilità e la selezione locale, non la capacità di eseguire il rendering.
3. Creazione cartella multimediale. GET/POST /media/folders.
4. Capability-gate i percorsi del dominio e spostali in /webadmin/api. Fatto e update e set primary sono arrivati con esso.

Cosa resta

Tutto ciò che è ancora contrassegnato come Mancante sopra è di secondo ordine: duplicazione della pagina e spostamento del sito, operazioni di massa, convertitore da HTML a blocco, eliminazione dei commenti, messaggi di contatto, creazione di schemi, reindicizzazione della ricerca e rapporti sui visitatori. Nessuno di essi impedisce a uno strumento di creare, controllare, correggere e pubblicare una pagina, che è ciò di cui si occupavano i livelli 1 e 2. Scegli tra loro in base alla domanda anziché scorrendo l'elenco.

Livello 3: confini deliberati

Utenti, emissione di token, impostazioni di sistema, ripristino/download del backup, creazione ed eliminazione di siti, clonazione, promozione e trasferimento rimangono solo nel pannello. Gli aggiornamenti di sistema sono disponibili tramite funzionalità API a livello di installazione concesse separatamente dalla versione 1.90.0. Sono elencati qui in modo che "non nell'API" sia una decisione registrata piuttosto che un'assenza non esaminata.

Dalla versione 1.92.0, l'installazione/aggiornamento/attivazione dell'API e del pannello applica automaticamente le modifiche richieste al database del plug-in e mantiene uno stato disabilitato dopo un errore. Abilita/configura utilizza lo stesso gate di compatibilità; le richieste incompatibili restituiscono HTTP 409 e plugin_incompatible. Dalla versione 1.94.0, la convalida dell'avvio viene eseguita in un nuovo processo prima dell'attivazione, gli aggiornamenti riusciti mantengono il pacchetto precedente e gli errori di origine/percorso di runtime mettono in quarantena il plug-in.

Il ripristino in /webadmin/plugin-recovery è una superficie del pannello autenticata separata. CMS 1.94.2 richiede uno Super admin attivo con normale accesso amministrativo. Può disabilitare un plug-in gestito in errore o ripristinare il pacchetto conservato solo quando non è stata eseguita alcuna migrazione del database. L'accesso tramite token a /plugins/* non sostituisce questa autorità di ripristino del browser. Vedi Sistema plugin.