profound-logoProfound CMS
⌘K
Admin
Theme
DocsGuidaBlogPhilosophy
DocsGuidaBlogPhilosophy

Hybrid

Instradamento parametricoTypes of ComponentsSetup server sent events (SSE) content refetchInstall Profound CMS as a proxyCEL Scripting in Template BuilderProject ScaffoldingMedia Library

Senza testa

Guida rapidaSplit Screen JSON Component Builder with LLMComponent Zod Pull

REST API

REST API OverviewgetConnect your websitegetGET /routesgetOttieni percorsogetGET /blocksgetGET /blocks/with-cel-cachegetGET /blocks/generatedgetGET /componentsgetGET /components/{name}getGET /dataset/{schema_name}getGET /content-changes (SSE)patchPATCH /dataset/{schema_name}postPOST /translationpatchPATCH /translationsgetGET /usagepostPOST /csvpatchPATCH /csv
All Systems Operational
Powered Byprofound-logo
Theme

REST API Overview

URL di base, schemi di autenticazione, risoluzione del tenant e modello di errore per l'API REST del CMS.

L'API REST di Profound CMS è fornita dal servizio Rust translation_manager. Espone endpoint headless di lettura/streaming utilizzati dal renderer, oltre a endpoint di scrittura per i contenuti, le traduzioni e l'importazione CSV.

Tutti gli esempi usano {CMS_API_URL} come URL di base dell'host della tua API CMS (ad esempio https://cms.dev.tryprofound.com). Non esiste alcun prefisso di percorso globale — le route sono montate alla radice, ad es. {CMS_API_URL}/routes.

Autenticazione

L'API utilizza due schemi distinti a seconda dell'endpoint.

Chiave API (letture headless + upsert delle varianti)

Invia la chiave come intestazione x-api-key oppure come parametro di query api_key:

curl '{CMS_API_URL}/dataset/post?websiteId=<uuid>' \
  -H 'x-api-key: <your-api-key>'

Le chiavi vengono convalidate tramite WorkOS e memorizzate temporaneamente in cache. Per gli endpoint di lettura, è richiesta una chiave API solo quando il server imposta require_schema_api_key = true; in caso contrario sono consentite letture anonime. L'upsert delle varianti (PATCH /dataset/{schema_name}) richiede sempre una chiave valida che includa l'autorizzazione content_write.

Utilizza l'autenticazione con chiave API: /routes, /route, /blocks*, /components*, /dataset/*, /schemas/*, /content-changes.

Bearer JWT (WorkOS)

Gli endpoint di gestione richiedono un JWT utente WorkOS:

curl '{CMS_API_URL}/usage?orgId=<uuid>' \
  -H 'Authorization: Bearer <workos-jwt>'

Utilizza l'autenticazione Bearer: /translation, /translations, /usage, /csv.

Risoluzione del sito web (tenant)

Gli endpoint con chiave API determinano il sito web di destinazione in questo ordine:

  1. Il parametro di query ?websiteId=<uuid>
  2. L'intestazione Host, confrontata con un dominio del sito web configurato
  3. Il fallback CMS_WEBSITE_ID (single-tenant / sviluppo locale)

Se nessuno di questi produce un UUID valido, l'endpoint restituisce 400.

Modello di errore

StatoSignificato
400Richiesta non valida — websiteId mancante/non valido, UUID non valido o errore di validazione
401Credenziali mancanti o non valide
403Autenticato ma privo di un'autorizzazione necessaria
404Risorsa non trovata
500Errore interno / del database

Controllo integrità

GET {CMS_API_URL}/health restituisce { "status": "ok" } e non richiede autenticazione — usalo per i controlli di vivacità.

Continue Reading
NextConnect your website›