Tú construyes la web. El equipo de tu cliente edita los textos, las imágenes y los precios. La Content API de Diil está en medio y le entrega a tu código JSON limpio, así que nadie tendrá que volver a abrir una pull request para corregir una errata del hero.
¿Qué es la Content API de Diil?
Diil es un editor visual de sitios web con un CRM incorporado. Los editores cambian el contenido en dos sitios: en el CRM o directamente en la web en producción con el modo Live: clic en un título, escribir, guardar. La Content API es la puerta de solo lectura por la que tu web recibe ese contenido.
Dicho de otro modo, es la API de un CMS headless: nosotros guardamos y servimos el contenido y tú mantienes el control total del frontend: el stack, el diseño, el hosting, el pipeline de build. Nunca tocamos tu HTML y tú nunca tienes que montar un panel de administración.
Cómo funciona
Toda la arquitectura cabe en un dibujo:
Editores Diil Tu web
──────── ──── ──────
CRM ────────┐
├──► pages → sections → blocks ──► Content API ──► fetch() ──► tus plantillas
Modo Live ──┘ (cada edición sube la solo lectura x-crm-key React, Vue, HTML…
(en tu web) versión del contenido) JSON por HTTPS- Los editores escriben. El contenido se organiza en páginas, secciones y bloques, cada uno con un marcador corto como
home,heroohero_title. Con los marcadores tu código encuentra las cosas. Más sobre esto en Cómo se organiza el contenido. - Tu web lee. Una sola petición
GETcon la clave del sitio devuelve una página entera: todas las secciones, todos los bloques, todas las traducciones que hayas pedido. - Los cambios aparecen solos. Cualquier edición en el CRM sube la versión del contenido del sitio, así que la siguiente petición ya recibe datos frescos. Puede que los visitantes lo vean un minuto más tarde por la caché del navegador y del CDN: échale un ojo a Caché y ETag.
¿Quieres que los editores hagan clic directamente en tus páginas reales en vez de rellenar formularios? Añade una etiqueta script y unos cuantos atributos data-crm-*: eso es la edición en vivo, y funciona sobre la misma API.
Qué puedes construir
Si sabe enviar una petición HTTP y parsear JSON, puede usar Diil. Sin SDK que instalar, sin atarte a ningún framework.
- Next.js, Nuxt, Astro, SvelteKit: fetch en el servidor, caché con revalidación y páginas rápidas como estáticas con contenido editable.
- HTML + JavaScript a pelo: una landing en cualquier hosting, un
fetch()y listo. - SPA en React o Vue: la clave del sitio es pública por diseño, así que llamar a la API desde el navegador está bien.
- Apps móviles: textos de onboarding, banners promocionales y FAQ que cambian sin publicar una versión en la tienda.
- Webs multidioma: cada bloque de texto llega como un mapa de idiomas; pide uno o varios en una sola petición.
- Blogs: posts con portada, autor, publicación programada y paginación a través de /v1/blog.
Una muestra de 10 segundos
Aquí tienes un bloque, el titular de la home, pedido por marcador. Pon tu propia clave y funciona tal cual:
curl "https://back.sitecog.com/content/v1/blocks/hero_title?section=hero&lang=en" \
-H "x-crm-key: pk_3f9c2a7e1b4d4c0e8a6f5b2d9c1e7a40"const res = await fetch('https://back.sitecog.com/content/v1/blocks/hero_title?section=hero&lang=en', {
headers: { 'x-crm-key': 'pk_3f9c2a7e1b4d4c0e8a6f5b2d9c1e7a40' },
});
const block = await res.json();
console.log(block.content.en); // "Earbuds that mute the city"{
"id": 95,
"marker": "hero_title",
"name": "Hero title",
"type": "text",
"multilang": true,
"updatedAt": "2026-09-20T16:33:23.000Z",
"content": { "en": "Earbuds that mute the city" }
}Y ya está. El texto llega como mapa de idiomas, las imágenes como { "file": "https://…" }, los enlaces como { url, target, title }; todas las formas están en Tipos de bloque.
La API de un vistazo
Todos los endpoints viven bajo https://back.sitecog.com/content, todos son GET (y HEAD) y todos devuelven JSON.
| Endpoint | Qué obtienes |
|---|---|
/v1/langs | Los idiomas activos del sitio, en el orden que fijaron los editores. Perfecto para un selector de idioma. |
/v1/pages | Todas las páginas, sin contenido: para menús y sitemaps. |
/v1/pages/:marker | Una página con todas sus secciones y bloques. Tu herramienta del día a día. |
/v1/sections/:marker | Una sección con sus bloques. |
/v1/blocks/:marker | Exactamente un bloque: un teléfono, un banner, un precio. |
/v1/blog | Los posts publicados del blog, con paginación. |
/v1/blog/:slug | Un post con su cuerpo en HTML. |
Algunas cosas que ya hemos resuelto por ti
- Una petición por página. Nada de cascadas de fetch: la página llega con todo dentro.
- Búsqueda por marcador, no por id. Las respuestas son objetos indexados por marcador, así que
page.content.herofunciona sin más. - Claves públicas de solo lectura. Una clave de sitio solo puede leer el contenido publicado de un sitio, así que es segura en el código del navegador. Mira Claves del sitio.
- Idiomas honestos. Pide los idiomas que necesitas con
?lang=en,de. Una traducción que falta simplemente no aparece: el fallback lo decides tú (así se hace). - Caché HTTP de serie. Cada respuesta correcta lleva un ETag, así que con
If-None-Matchconsigues un304 Not Modifiedbaratísimo. - Límites generosos. 300 peticiones por minuto por IP y 600 por clave: con un poco de caché no los tocarás nunca. Detalles en Límites de peticiones.