Diil Docs
  1. Documentación

Diil Content API: tu web, nuestro contenido

Actualizado:

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:

La foto completatext
  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
  1. Los editores escriben. El contenido se organiza en páginas, secciones y bloques, cada uno con un marcador corto como home, hero o hero_title. Con los marcadores tu código encuentra las cosas. Más sobre esto en Cómo se organiza el contenido.
  2. Tu web lee. Una sola petición GET con la clave del sitio devuelve una página entera: todas las secciones, todos los bloques, todas las traducciones que hayas pedido.
  3. 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"
200 OKjson
{
  "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.

EndpointQué obtienes
/v1/langsLos idiomas activos del sitio, en el orden que fijaron los editores. Perfecto para un selector de idioma.
/v1/pagesTodas las páginas, sin contenido: para menús y sitemaps.
/v1/pages/:markerUna página con todas sus secciones y bloques. Tu herramienta del día a día.
/v1/sections/:markerUna sección con sus bloques.
/v1/blocks/:markerExactamente un bloque: un teléfono, un banner, un precio.
/v1/blogLos posts publicados del blog, con paginación.
/v1/blog/:slugUn 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.hero funciona 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-Match consigues un 304 Not Modified baratí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.

Por dónde seguir