API e Integraciones

Chinaski está diseñado para ser automatizado: una API REST para scripts y pipelines, webhooks salientes para otros sistemas y un servidor de Model Context Protocol para que los asistentes de IA trabajen el CMS directamente. Esta sección cubre los tres.

En esta sección

• Servidor MCP; el servidor Jinja JSON-RPC sobre stdio que expone el CMS a Claude Code y otros clientes MCP; configuración, sesiones, reintentos y las familias de herramientas.
• Referencia de herramientas MCP; la referencia por herramienta: argumentos, comportamiento y las herramientas de composición de nivel superior.
• Webhooks; los cuatro tipos de eventos salientes (form, post, publish, build), formas del payload, firma, reintentos y el registro de entregas.
• Automatización; la superficie de API de máquina: API keys (ámbitos de lectura/escritura, límites de tasa, expiración), los endpoints /api/* (lecturas, creaciones/actualizaciones, upserts, jobs por lotes, disparadores de build) y los endpoints de health para monitores.

Dos audiencias, dos puertas

• Las máquinas que quieren hacer scripting de Chinaski hablan REST con una API key: lecturas para reportes, create/update para pipelines, jobs para importaciones por lotes y el disparador de build. Todo se audita por key, y una key puede tener ámbito de lectura o de escritura.
• Los asistentes que quieren trabajar el CMS pasan por el servidor MCP integrado; un proceso por proyecto, JSON-RPC sobre stdio, respaldado por el mismo modelo de API keys; añade herramientas de nivel superior (crear con blocks, traducir, importación masiva, auditorías) sobre los verbos REST.

Lo que sale hacia afuera

La superficie de API también incluye webhooks salientes; eventos que el CMS te envía: submissions, cambios de posts, publish programados y builds terminados, cada uno firmable con un secret HMAC. El modo air-gap desactiva todo eso (y todas las demás llamadas salientes) hasta que una integración se habilite deliberadamente.

Lo que la API no hará

• No hay endpoints públicos de comentarios/feed (esos no existen).
• No hay verbos DELETE; la eliminación permanece en el admin UI para evitar pérdida accidental de datos inducida por automatización; el estado de publish y el trash siguen siendo operaciones manuales o de nivel editor.
• No hay suplantación de sesión de admin mediante keys: las API keys no cargan identidad ni roles de usuario; actúan como su propio actor en el audit trail.