Diil Content API: your site, our content

You build the website. Your client's team edits the words, the pictures and the prices. The Diil Content API sits in between and hands your code clean JSON — so nobody has to open a pull request to fix a typo in the hero ever again.

#What is the Diil Content API?

Diil is a visual website editor with a CRM attached. Editors change content in two places: in the CRM, or right on the live site in Live mode — click a heading, type, save. The Content API is the read-only door through which your site gets that content.

In other words, it is a headless CMS API: we store and serve the content, you keep full control of the frontend — the stack, the design, the hosting, the build pipeline. We never touch your HTML; you never have to build an admin panel.

#How it works

The whole architecture fits in one picture:

  Editors                     Diil                              Your site
  ───────                     ────                              ─────────

  CRM ────────┐
              ├──►  pages → sections → blocks  ──►  Content API  ──►  fetch() ──►  your templates
  Live mode ──┘     (every edit bumps the            read-only         x-crm-key     React, Vue, HTML…
  (on your site)     site's content version)         JSON over HTTPS

1. Editors write. Content is organised into pages, sections and blocks, each with a short marker like home, hero or hero_title. Markers are how your code finds things. More on that in How content is organised.
2. Your site reads. One GET request with a site key returns a whole page — every section, every block, every translation you asked for.
3. Changes show up on their own. Any edit in the CRM bumps the site's content version, so the very next request gets fresh data. Visitors may see it about a minute later because of browser and CDN caching — see Caching & ETag.

Want editors to click right on your real pages instead of filling forms? Add one script tag and a few data-crm-* attributes — that is live editing, and it works on top of the same API.

#What you can build

If it can send an HTTP request and parse JSON, it can use Diil. No SDK to install, no framework lock-in.

• Next.js, Nuxt, Astro, SvelteKit — fetch on the server, cache with revalidation, ship static-fast pages with editable content.
• Plain HTML + JavaScript — a landing page on any hosting, one fetch() and you are done.
• React or Vue single-page apps — the site key is public by design, so calling the API from the browser is fine.
• Mobile apps — onboarding texts, promo banners and FAQs that change without a store release.
• Multilingual sites — every text block comes as a language map; ask for one language or several in a single request.
• Blogs — posts with covers, authors, scheduled publishing and pagination via /v1/blog.

#A 10-second taste

Here is one block — the headline of the home page — fetched by marker. Swap in your own key and it works as is:

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" }
}

That's it. Text comes as a language map, images as { "file": "https://…" }, links as { url, target, title } — every shape is listed on Block types.

#The API at a glance

All endpoints live under https://back.sitecog.com/content, all are GET (and HEAD), all return JSON.

#A few things we got right for you

• One request per page. No waterfall of fetches — the page arrives with everything inside.
• Lookups by marker, not by id. Responses are objects keyed by marker, so page.content.hero just works.
• Public, read-only keys. A site key can only read published content of one site, so it is safe in browser code. See Site keys.
• Honest languages. Ask for the languages you need with ?lang=en,de. A missing translation is simply absent — you decide the fallback (here is how).
• HTTP caching built in. Every successful response carries an ETag, so If-None-Match gets you a cheap 304 Not Modified.
• Generous limits. 300 requests per minute per IP and 600 per key — with a little caching you will never meet them. Details in Rate limits.

#Where to go next