Content API

Content API

Sardine can publish the site's content as static, versioned JSON alongside the HTML. There is no server component and no authentication: the files are part of the build output and are served by whatever hosts the site.

Enabling it

[build]
content_api = true

Every build then also writes the API files under api/v1/.

Endpoints

Path	Contents
/api/v1/site.json	Site metadata: name, base URL, blog path, languages, categories
/api/v1/<lang>/content.json	All published articles and pages for one language

Response contract

Every file carries version — the API version it speaks.

• site.json — name, base_url, blog_path, languages (codes, source language first) and categories (slug → per-language labels).
• <lang>/content.json — language plus articles (id, per-language slug and URL, title, summary, safe rendered body_html, ISO 8601 date, author, featured flag, category, tags, cover metadata including focal when an editor set one, sources ({type, srcset} modern-format alternatives, possibly empty) and srcset when image derivatives are configured, custom fields) and pages (id, slug, URL, title, description, sections with key, kind, resolved fields and images).

Articles and pages additionally carry seo when an editor set per-entry overrides (seo_title, seo_description, noindex, canonical, og_image) — absent otherwise.

Guarantees

• Only published content: the API lists exactly what the built site publishes — no drafts, trashed entries or entries outside their publication window; a language file only lists entries whose translation is complete.
• Stable within a version: fields may be added within v1; renames or removals only ever happen under a new /api/vN/ path, so a consumer pinned to /api/v1/ keeps working.
• Static and cacheable: plain UTF-8 JSON files on the same host as the site — cache and CDN them like any other static asset.

Live example: https://sardine.ph7x.com/api/v1/site.json.