Search "content api" and Google hands you two products that have almost nothing to do with each other. One is Google's Content API for Shopping, a feed pipeline for pushing e-commerce inventory into shopping catalogs. The other is the content delivery API that a headless CMS exposes to serve your articles as JSON. If you are building a blog, you want the second one, and the results page barely separates them. This guide is about the content delivery API that powers a modern blog: what it is, how it differs from a content management API, and how the request-to-render path actually works.
Key takeaways
- A content API for a blog is a REST endpoint that returns your articles as structured JSON, so any front end can fetch and render them without a vendor SDK.
- "Content API" splits into two jobs: a content delivery API (read, for your public site) and a content management API (write, for authoring). Almost all blog traffic runs on the delivery side.
- The delivery API is what makes a CMS headless: storage lives in the CMS, presentation lives in your front end, whether that is Next.js, Nuxt, SvelteKit, Astro, React, or Vue.
- A clean response includes id, title, slug, content, excerpt, language, and a link between translations, and needs no vendor SDK to consume.
- Kamaan's REST API Delivery returns that JSON shape from one endpoint across every site in your account, on every tier, starting with Starter.
What a content API actually is
A content API is a programmatic interface that lets your code read and manage content in a CMS without touching the CMS's own screens. For a blog, your front end asks the API for articles and gets back structured data, usually JSON, instead of a finished web page. The CMS stores and manages the content; your application decides how it looks.
This is the headless split. A traditional CMS like classic WordPress owns both the content and the theme that renders it, which is why the front end and the database end up welded together. A headless CMS breaks them apart and hands your front end a content API instead of an HTML page. If you want the ground-level version of that distinction, the plain-English guide to what a headless CMS is sets up the terms this article uses.
The name causes real confusion because "content API" is overloaded. In the search results for the term, the top spots go to Google's Content API for Shopping and Microsoft's Advertising Content API, which are e-commerce feed tools for managing product listings, not blog posts. The content API a blog uses is the CMS delivery endpoint, the same category as the Ghost Content API or Contentful's content delivery API. Same two words, different job, so whenever you open documentation labeled "content API," check first whether it serves products or articles.
Content delivery API vs content management API
Inside the CMS category, "content API" splits again into two endpoints with opposite jobs. Getting this right saves you from shipping a write key to a browser, or trying to publish through a read-only endpoint.
| Dimension | Content delivery API | Content management API |
|---|---|---|
| Job | Read published content for your site | Create, update, and delete content |
| Direction | CMS to front end (GET) | Authoring tool to CMS (POST, PUT, DELETE) |
| Who calls it | Your public blog, at build or request time | Editors, scripts, migration jobs |
| Auth | Read-only key, safe to cache | Write-scoped key, never in the browser |
| Traffic | High volume, cacheable | Low volume, rarely cached |
| Powers | The rendered blog readers see | The editing and publishing workflow |
Most of what "a content API powers a blog" means lives in the left column. Readers hit your pages thousands of times for every one time an editor publishes, so the delivery API carries the load and the management API carries the workflow. When the rest of this article says content delivery API, it means the read side: the endpoint your Next.js or Astro site calls to list posts and fetch a single article by slug.
How a content delivery API powers a blog, end to end
Walk the path a single article takes from your CMS to a reader's screen. There are four steps, and the content delivery API is the hinge in the middle.
- Author and store. You write the post in the CMS, add a title, slug, excerpt, and SEO fields, and publish. The content now lives in the CMS, not baked into your app's codebase.
- Request. Your front end calls the delivery API. A list request pulls every published article; a detail request pulls one by slug. A request looks like this:
GET https://api.kamaan.io/v1/sites/{site_id}/articles?language=en&status=published
Authorization: Bearer <read_only_key>
- Receive JSON. The API returns an array of article objects. A single item carries the shape a blog actually needs:
{
"id": "art_2k1nB7Vy8q",
"title": "Content API: How a Content Delivery API Powers a Modern Blog",
"slug": "content-api",
"content": "# Content API\n\nSearch \"content api\" and...",
"excerpt": "What a content delivery API is and how it powers a blog.",
"language": "en",
"parent_article_id": null,
"status": "published",
"published_at": "2026-07-25T09:00:00Z"
}
- Render. Your front end maps that JSON onto components and renders the page in its own design. The
contentfield is usually markdown or HTML that you parse with a library your framework already has. Because the shape is plain JSON, no vendor SDK is required: the nativefetchin any modern runtime is enough.
That is the whole loop, and the reason it matters is portability. The same JSON can feed a Next.js marketing site, an Astro docs site, and a React dashboard at once, because none of them depend on how the others render. For the full per-framework fetch code, the companion piece on how a blog API works across frameworks has the copy-paste version for Next.js, Nuxt, SvelteKit, Astro, and React.
Content API options compared
Every headless CMS exposes a content delivery API, so the endpoint itself is table stakes. What differs is the pricing model wrapped around it, whether translations come back through the same endpoint, and how many sites one account covers. Verify current pricing before you commit, since these figures move.
| Content API | Delivery format | Native multilingual delivery | Multi-site model | Entry pricing |
|---|---|---|---|---|
| Kamaan | REST, standard JSON | Yes, same endpoint by language | One account, tiered site count | Starter, flat monthly rate, 1 site |
| Contentful | REST and GraphQL | Locale-based, add-on modeling | Per space, per blog | First paid tier around $300/mo |
| Sanity | REST and GROQ query language | Via schema you model yourself | Per project | Free tier, then usage-based |
| Ghost | REST Content API | No native multilingual | Per site | Ghost Pro from around $9/mo per site |
The pattern is consistent: the delivery API is a commodity; the pricing model around it is not. Contentful charges per space, so a founder with three product blogs pays for three spaces. Sanity offers a generous free tier but expects you to model content as schema-as-code before the API returns anything, which is real configuration for what is, on a blog, just posts. Ghost delivers clean JSON but has no native multilingual, so a second language becomes an extension or a workaround. If you are weighing these side by side, the honest comparison of headless CMS options for startups does the pricing math per team size.
Why teams outgrow their first content API
The delivery API is easy to adopt and easy to regret, and the regret rarely comes from the endpoint. It comes from three things bolted around it.
The first is the per-space wall. You picked a CMS for one blog, it worked, then you launched a second product. Now you pay and log in per space, running the same workflow two, three, or five times. The API was never the problem; the account model was.
The second is schema ceremony. Some content APIs will not return a post until you have modeled the post type as code. For a structured product catalog that is the right call. For a blog, where the shape is title, body, slug, and SEO fields, it is configuration you should not have to write just to fetch an article.
The third is multilingual. A content API that returns one language forces your team to duplicate posts and hand-maintain hreflang across every locale, which breaks quietly at scale. A delivery API that returns translations through the same endpoint, keyed by a language parameter, keeps that logic out of your routing layer. That is the difference between multilingual being a setting and multilingual being a project.
Wiring a content delivery API into your blog
The path from an empty front end to a live, API-driven blog is short once you know the four moves, and the sequence is the same whether your stack is Next.js or Astro.
- Get a read-only key. Generate a delivery key scoped to read. Keep any write-scoped key on the server only, never in a client bundle.
- Call the list endpoint. Fetch published articles for the language you want and render them as an index page. This is one
fetchand amap. - Call the detail endpoint by slug. On each article route, fetch the single post by its slug and render the
contentfield with a markdown parser your framework already ships. - Cache and add locales. Marketing content changes rarely, so cache responses for five to ten minutes or build them statically, then repeat the language parameter for each locale.
First-time wiring is honestly 40 to 60 minutes for a developer, including environment variables, the index and detail routes, and a sitemap. Every blog after that reuses the same fetch pattern. For the Next.js version with incremental static regeneration, the Next.js headless CMS setup guide walks the specifics, and the architectural decision behind all of it sits in the pillar on how to add a blog to your SaaS.
Two real-world scenarios
A solo founder shipping one product blog. She runs a single SaaS on Next.js and wants a blog that ranks without a second system to babysit. She points her front end at Kamaan's REST API Delivery on the Starter tier, one site and one language, with 5,000 API calls a month, enough for a marketing blog that revalidates every ten minutes. She drafts posts in the Article CMS, and her front end renders them from the same JSON shape shown above.
A multi-product founder running three SaaS blogs. He has three products on three different stacks: one Next.js, one Astro, one React dashboard. Rather than run three CMS accounts, he manages all three from one Kamaan account on the Growth tier, three sites and three languages. Each front end calls the same delivery endpoint with its own site id, and Auto-Multilingual Delivery returns translations on that endpoint by language, so his routing layer never branches on locale. One content library, three blogs, one bill.
The delivery API is a commodity every headless CMS ships. What decides the tool is how it prices the second blog and whether the second language comes back through the same endpoint.
Where Kamaan fits
Kamaan is a headless blog CMS built for the people who run more than one SaaS blog. You manage every blog from one account and dashboard, and you can run every operation, from writing to translating to publishing, across all of them from Claude, ChatGPT, Cursor, or any MCP client through the MCP Server and ChatGPT Actions. The part this article covers, REST API Delivery, returns one JSON shape across every site in your account, into Next.js, Nuxt, SvelteKit, Astro, React, or Vue. The delivery endpoint is the same for one blog or twenty, and translations arrive through it automatically when you publish, each at its own URL with correct hreflang emitted server-side.
FAQ
What is a content API?
A content API is an HTTP endpoint that returns content as structured data, usually JSON, so your code can read or manage it without using the CMS interface. For a blog, your front end calls the content delivery API, receives the articles, and renders them in your own design. The CMS handles storage and editing; your application handles presentation.
What is the difference between a content delivery API and a content management API?
A content delivery API is read-only and serves published content to your public site, so it is high traffic and safe to cache. A content management API is write-capable and handles creating, updating, and deleting content, so it uses a write-scoped key that must stay on the server. A blog's public pages run almost entirely on the delivery side.
Is a content API the same as a headless CMS?
No, but they are closely linked. A headless CMS is the whole system that stores and manages your content; the content API is the interface it exposes so your front end can fetch that content. The API is what makes the CMS "headless," because it hands your code JSON instead of a rendered page.
Do I need an SDK to use a content API?
No. If the content API returns standard JSON over REST, the native fetch built into every modern JavaScript runtime is enough. Vendor SDKs add convenience like typed responses, but they also lock your code to that vendor's client library, while a plain REST endpoint stays portable across frameworks and versions.
Can one content API feed multiple front ends?
Yes, and that is the main reason to go headless. The same delivery endpoint can serve a Next.js marketing site, an Astro docs site, and a React dashboard at once. With Kamaan, one account's delivery API serves every site you run from a single JSON shape.
How does a content API handle translations?
The clean approach returns each translation as its own article object, linked to the source and requested through the same endpoint by a language parameter. Kamaan's Auto-Multilingual Delivery works this way: publish once in English and the translated versions come back from the same articles endpoint by passing language=de, language=fr, and so on, each at its own URL with correct hreflang.
Related on Kamaan
- What is a headless CMS explains the storage-versus-rendering split this article assumes.
- Blog API: fetch and render in any framework has the copy-paste fetch code for Next.js, Nuxt, SvelteKit, Astro, and React.
- Headless CMS for Next.js goes deeper on caching, revalidation, and image handling.
- How to add a blog to your SaaS is the pillar on the architectural decision before you wire any code.
- Best headless CMS for startups compares pricing and operational fit for early-stage teams.
Start building with Kamaan
One content API, every blog you run, delivered as clean JSON. You point your front end at one REST endpoint, and the same shape renders across Next.js, Nuxt, SvelteKit, Astro, React, or Vue. Translations arrive through the same endpoint when you publish, so international SEO stops being a hand-maintained job.
Kamaan gives you a headless blog CMS designed for SaaS founders, with REST API Delivery, the MCP Server, and ChatGPT Actions on every tier. Starter covers one site and one language; Growth covers three sites when you are ready. First month is free.
