profound-logoProfound CMS
⌘K
Admin
Theme
DocsTutorialBlogPhilosophy
DocsTutorialBlogPhilosophy

Hybrid

Collection of Pages with ComponentsTypes of ComponentsSetup server sent events (SSE) content refetchInstall Profound CMS as a proxyScripts dans le générateur de modÚlesProject ScaffoldingBibliothÚque multimédia

Sans interface

Démarrage rapideSplit Screen JSON Component Builder with LLMComponent Zod Pull

API REST

REST API OverviewgetConnect your websitegetGET /routesgetGET /routegetGET /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 de base, mécanismes d'authentification, résolution du locataire et modÚle d'erreur pour l'API REST du CMS.

L'API REST de Profound CMS est fournie par le service Rust translation_manager. Elle expose des points de terminaison headless de lecture/flux utilisés par le moteur de rendu, ainsi que des points de terminaison d'écriture pour le contenu, la traduction et l'importation CSV.

Tous les exemples utilisent {CMS_API_URL} comme URL de base de votre hĂŽte d'API CMS (par exemple https://cms.dev.tryprofound.com). Il n'y a aucun prĂ©fixe de chemin global — les routes sont montĂ©es Ă  la racine, par ex. {CMS_API_URL}/routes.

Authentification

L'API utilise deux mécanismes distincts selon le point de terminaison.

Clé d'API (lectures headless + upsert de variante)

Envoyez la clĂ© dans l'en-tĂȘte x-api-key ou le paramĂštre de requĂȘte api_key :

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

Les clés sont validées auprÚs de WorkOS et mises briÚvement en cache en mémoire. Pour les points de terminaison de lecture, une clé d'API n'est requise que lorsque le serveur définit require_schema_api_key = true; autrement, les lectures anonymes sont autorisées. L'upsert de variante (PATCH /dataset/{schema_name}) exige toujours une clé valide portant la permission content_write.

Utilise l'authentification par clé d'API : /routes, /route, /blocks*, /components*, /dataset/*, /schemas/*, /content-changes.

JWT Bearer (WorkOS)

Les points de terminaison de gestion nécessitent un JWT utilisateur WorkOS :

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

Utilise l'authentification Bearer : /translation, /translations, /usage, /csv.

Résolution du site web (locataire)

Les points de terminaison utilisant une clé d'API déterminent le site web cible dans cet ordre :

  1. Le paramĂštre de requĂȘte ?websiteId=<uuid>
  2. L'en-tĂȘte Host, comparĂ© Ă  un domaine de site web configurĂ©
  3. La valeur de repli CMS_WEBSITE_ID (mono-locataire / développement local)

Si aucun ne se résout en UUID valide, le point de terminaison renvoie 400.

ModĂšle d'erreur

StatutSignification
400Mauvaise requĂȘte — websiteId manquant/invalide, UUID invalide ou Ă©chec de validation
401Identifiants manquants ou invalides
403Authentifié mais permission requise manquante
404Ressource introuvable
500Erreur interne / base de données

Vérification d'état

GET {CMS_API_URL}/health renvoie { "status": "ok" } et ne nĂ©cessite aucune authentification — utilisez-le pour les sondes de vivacitĂ©.

Continue Reading
NextConnect your websiteâ€ș