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 proxyCEL Scripting in Template BuilderProject ScaffoldingBiblioteca multimedia

Sin interfaz

Inicio rápidojson y código de ClaudeComponent Zod Pull

Api rest

Visión general de la API RESTgetConnect 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}postTraducción de publicacionespatchPATCH /translationsgetGET /usagepostPOST /csvpatchPATCH /csv
All Systems Operational
Powered Byprofound-logo
Theme

Visión general de la API REST

URL base, esquemas de autenticación, resolución del tenant y el modelo de errores de la API REST del CMS.

La API REST de Profound CMS es servida por el servicio de Rust translation_manager. Expone endpoints headless de lectura/transmisión utilizados por el renderizador, además de endpoints de escritura para contenido, traducción e importación de CSV.

Todos los ejemplos utilizan {CMS_API_URL} como la URL base de tu host de API del CMS (por ejemplo https://cms.dev.tryprofound.com). No hay prefijo de ruta global: las rutas se montan en la raíz, p. ej. {CMS_API_URL}/routes.

Autenticación

La API utiliza dos esquemas diferentes según el endpoint.

Clave de API (lecturas headless + upsert de variantes)

Envía la clave como el encabezado x-api-key o el parámetro de consulta api_key:

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

Las claves se validan frente a WorkOS y se almacenan brevemente en caché en memoria. Para los endpoints de lectura, solo se requiere una clave de API cuando el servidor establece require_schema_api_key = true; de lo contrario, se permiten lecturas anónimas. El upsert de variantes (PATCH /dataset/{schema_name}) siempre requiere una clave válida que tenga el permiso content_write.

Utiliza autenticación con clave de API: /routes, /route, /blocks*, /components*, /dataset/*, /schemas/*, /content-changes.

JWT Bearer (WorkOS)

Los endpoints de administración requieren un JWT de usuario de WorkOS:

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

Utiliza autenticación Bearer: /translation, /translations, /usage, /csv.

Resolución del sitio web (tenant)

Los endpoints con clave de API resuelven el sitio web de destino en este orden:

  1. El parámetro de consulta ?websiteId=<uuid>
  2. El encabezado Host, comparado con un dominio de sitio web configurado
  3. La alternativa CMS_WEBSITE_ID (tenant único / desarrollo local)

Si ninguno se resuelve en un UUID válido, el endpoint devuelve 400.

Modelo de errores

EstadoSignificado
400Solicitud incorrecta — falta/websiteId inválido, UUID inválido o error de validación
401Credenciales ausentes o inválidas
403Autenticado pero falta un permiso requerido
404Recurso no encontrado
500Error interno / de base de datos

Comprobación de estado

GET {CMS_API_URL}/health devuelve { "status": "ok" } y no necesita autenticación — úsalo para sondas de actividad.

Continue Reading
NextConnect your website›