Automatización

Chinaski expone una API JSON REST para que scripts, jobs de cron y asistentes de IA lean tu contenido, lo creen y actualicen, disparen builds y ejecuten jobs por lotes; todo lo que normalmente harías clic en el área de admin, menos el borrado. Esta página es la orientación para automatizar contra ella; la referencia endpoint a endpoint está en otra parte de la sección Reference, y la superficie de asistentes de IA tiene su propia página de MCP.

Autenticación

El acceso automatizado usa API keys, creadas por un admin bajo Settings → API Keys. Cada key tiene nombre, tiene su propia fecha de expiración (opcional) y tiene ámbito read o write:

Las keys read pueden obtener datos pero nunca modificar contenido.
Las keys write pueden crear y actualizar; explícitamente requeridas para cualquier llamada POST/PUT, sin importar lo que haría el handler.
Las peticiones se identifican con un header X-API-Key. Las keys faltantes o expiradas obtienen un 401; una key read que intenta una escritura obtiene un 403.

El acceso a la API puede apagarse por completo desde la pestaña API Keys del admin; con ella apagada, cada petición de API responde 503 "API access is disabled".

El límite de tasa es por key, por 60 segundos, con un valor por defecto de 100 peticiones por minuto (configurable en Settings). Excederlo devuelve un 429 con un header Retry-After que te indica cuánto esperar.

Cada uso de key se registra en el audit trail con el método y path HTTP, y el timestamp de último uso se rastrea por key; útil para encontrar keys que deberían retirarse.

Lo que la API puede hacer

Leer; páginas publicadas, posts, blocks, snippets, categorías, documentos, navegación, redirects, authors, custom fields, cobertura de traducción y workflows, búsqueda por palabra clave, reportes de content-gap y todas las settings no secretas. Las listas están paginadas (data más un bloque meta con total/page/limit/pages) y recortadas a menos que pidas filas completas.
Crear y actualizar; POST/PUT para páginas, posts, blocks, snippets, categorías, documentos, authors y nav items, incluyendo variantes upsert que crean-o-actualizan por slug e idioma, más configuración de webhooks y escrituras de settings. Los valores secretos de settings se cifran al entrar, las keys desconocidas se rechazan por ítem, y los valores de URL de webhook se validan por seguridad.
Build; POST de un trigger para rebuild del site estático (la respuesta reporta dispatched / already-busy / missing), luego GET del build status para el progreso por idioma: páginas y posts listos vs. total, ítem actual y mensaje de error.
El borrado no está en la API; no hay endpoints DELETE; el borrado permanente o al trash sucede en el admin UI. Los scripts que necesiten retirar contenido deberían publicar/marcar en lugar de borrar, o hacer el borrado a mano.

Jobs por lotes

Para trabajo pesado, envía un job asíncrono en lugar de muchas llamadas individuales:

Enviar: POST /api/jobs con un tipo (bulk_upsert_pages, bulk_upsert_posts o bulk_create_blocks) y un array items no vacío.
Consultar: GET /api/jobs/:id devuelve el estado del job, el progreso (total y hecho) y el payload de resultado una vez terminado.

Monitoreo: el estado estilo GET /build/status también está expuesto; y GET /api/health es el endpoint de health sin autenticación que tu monitor de uptime puede golpear; reporta el estado, el conteo de páginas publicadas, la hora del último build y si un build está en progreso, y marca una advertencia si hubo páginas publicadas pero nunca un build.

Workflows asistidos por IA

El servidor MCP integrado es la puerta de entrada prevista para asistentes de IA como Claude Code: se lanza localmente como un proceso JSON-RPC-over-stdio, habla con esta misma API REST usando una API key y expone herramientas de nivel superior encima; creación de páginas/posts en una llamada con blocks, traducción de contenido con auditoría automática de gaps, importación/upsert en masa, limpieza de orphan blocks y auditorías de calidad de contenido. Apúntalo a la URL de tu CMS y a una API key con capacidad de escritura y tu asistente trabaja directamente contra la API.

Buenos hábitos para scripts

Dale a los scripts sus propias API keys con nombre para que las entradas de auditoría los identifiquen distintamente, y establece una expiración en las keys temporales. El uso de keys actualiza last_used_at auditado; limpia las no usadas desde la pestaña API Keys.
Toma en serio la separación read/write: una key que solo lee no debería tener permiso de escritura "por si acaso".
Cuida los secrets: las settings obtenidas por la API nunca incluyen valores secretos (la contraseña SMTP y los secrets de webhook siempre se omiten), y la ruta de escritura cifra los nuevos valores secretos correctamente.