What Is a Content API? How Headless CMS Delivers Content

Your CMS has a website. But what if it also had a programmable outlet for every other app you build? That's the job of a content API — and once you understand how it works, you'll wonder how you built anything without one.

TL;DR: A content API is an HTTP endpoint that your CMS exposes so any app — a mobile app, a Next.js site, a digital sign, a voice assistant — can pull content on demand. Instead of your CMS controlling the front-end, your front-end fetches exactly the data it needs in JSON format. The CMS handles editing and storage. Everything else is up to you.

What Is a Content API?

A content API is an HTTP interface your CMS exposes that returns content as structured data — typically JSON. You call it from your code, it returns posts, pages, settings, or menus, and you render that data however you like.

That's it. No theme engine. No server-side templates. No PHP rendering HTML on a page load. Just data, on demand, over HTTP.

If you've worked with any third-party API — Stripe, Twilio, Mapbox — a content API works the same way. You make a GET request to a URL, you get JSON back, you use it.

The reason this matters is delivery flexibility. A traditional CMS tightly couples content storage with content display. WordPress stores your posts AND renders your HTML. If you want your content on a mobile app, you either hack the WordPress theme layer or install a REST plugin and hope it stays maintained.

A content API breaks that coupling. Your editor writes in the CMS admin. Your developer fetches the content via API. The front-end could be Next.js, a React Native app, an Astro blog, or a custom dashboard — none of that matters to the CMS. It just serves JSON.

This is the core idea behind headless CMS architecture: remove the "head" (the front-end rendering layer) from the CMS and replace it with an API layer.

REST vs GraphQL Content APIs

Two formats dominate the content API space: REST and GraphQL. Both solve the same problem — delivering content as structured data — but they do it differently.

REST uses separate endpoints for each resource. You call /api/v1/posts for posts, /api/v1/pages for pages. The response shape is fixed by the server. It's simple to understand and works with plain fetch() calls in any language.

GraphQL uses a single endpoint where you write a query describing exactly what fields you want. The server returns precisely those fields — nothing more. It's more flexible but requires a query language and more setup on both sides.

For most teams starting with headless CMS, REST is the right call. It's easier to debug, caches well with standard HTTP tools, and doesn't require any special client libraries.

We cover the trade-offs in detail in API-First CMS: REST vs GraphQL for Content Delivery — worth reading once you've got REST working.

How a Content API Works — Step by Step

Here's what actually happens when a developer fetches content via a content API:

1. Your editor saves content in the CMS admin. They write a blog post, hit publish, and the post goes into the database. That's the end of the editor's job.

2. Your front-end app makes an HTTP GET request to a URL like /api/v1/posts. This happens at build time (static site), at runtime (server-side), or in the browser (client-side).

3. The CMS API server looks up the data, applies any filters (pagination, category, status), and serializes the result as JSON.

4. The API returns a JSON response. Your app receives it over the network — title, body, slug, published date, featured image URL, whatever fields the CMS exposes.

5. Your front-end renders it. You're in full control. Use it in a React component, an Astro page, a mobile screen, or a server-side template. The CMS doesn't care.

6. If content changes, webhooks notify your app. The CMS fires a signed HTTP POST to a URL you configure. Your app receives it and triggers a rebuild or cache invalidation.

That cycle — create in admin, fetch via API, render anywhere — is the entire headless model. The CMS is a writing and storage tool. The API is the distribution layer.

What You Can Build with a Content API

The value of a content API isn't academic — it's what becomes possible when content is no longer stuck inside one website.

Next.js marketing site with static generation. Call /api/v1/posts at build time with getStaticProps. Each blog post becomes a pre-rendered HTML page. Fast, SEO-friendly, zero CMS involvement at page load. When you publish a new post, a webhook triggers a rebuild.

Astro blog with island architecture. Astro fetches content at build time from the content API, renders everything as static HTML, and hydrates only the interactive parts. Same posts, different front-end, no CMS changes needed.

React Native mobile app. Your app hits the same /api/v1/posts endpoint as your website. Mobile readers get the same published content. Updates in the CMS appear on both web and mobile automatically.

Digital signage or kiosk display. A display app running on a TV or tablet pulls content from the API on a schedule. Your marketing team updates the CMS. The display refreshes. No developer needed for content changes.

Multi-locale site with a separate front-end per language. Each locale builds from the same content API but applies its own layout and routing rules. The CMS stores the content once.

This is why developers talk about "omnichannel" delivery — same content source, infinite output channels. You build it once in the CMS, the content API distributes it everywhere.

If you want to understand the architectural picture more clearly, the headless CMS vs traditional CMS comparison shows exactly where the rendering split happens.

What to Look For in a CMS Content API

Not all content APIs are equal. Here's what actually matters when you're evaluating one:

Authentication model. Public endpoints for read-only content (posts, pages, menus) should be unauthenticated — no token required. That way your static site can fetch without managing secrets at build time. Write operations (creating posts via API) should require a token. Look for Sanctum, JWT, or API key auth on write routes.

Rate limits. Know the limits before you build on them. An API that throttles at 10 requests per minute will break a search feature instantly. Reasonable default: 60 requests per minute on public endpoints is workable for most sites.

Webhook support. Without webhooks, you poll. Polling is slow and expensive. A good content API fires a signed HTTP POST to a URL you configure whenever content is published, updated, or deleted. The signature (typically HMAC-SHA256) lets you verify the request came from your CMS and not a random internet actor.

Response shape and filtering. Can you filter by category? Paginate? Sort by date? Get a single post by slug? The basic filtering capabilities of the API determine what you can build on top of it without hacking around it.

Error handling and status codes. A 404 on a missing slug should return {"error": "not found"}, not an HTML error page. Good APIs return JSON errors consistently.

Code Example: Fetching Posts from a Content API

Here's what a real fetch call looks like against UnfoldCMS's REST API. No SDK required — just fetch().

// Fetch the latest 5 published posts
const response = await fetch('https://yoursite.com/api/v1/posts?per_page=5');
const data = await response.json();

// data.data is the array of posts
data.data.forEach(post => {
  console.log(post.title, post.slug, post.published_at);
});

The response shape looks like this:

{
  "data": [
    {
      "id": 42,
      "title": "Getting Started with Headless CMS",
      "slug": "getting-started-headless-cms",
      "subtitle": "A practical intro for developers",
      "body": "<p>Your content here...</p>",
      "published_at": "2026-06-15T09:00:00Z",
      "category": {
        "id": 5,
        "name": "Headless CMS",
        "slug": "headless-cms"
      },
      "featured_image": "https://yoursite.com/storage/posts/getting-started.webp"
    }
  ],
  "meta": {
    "current_page": 1,
    "per_page": 5,
    "total": 38,
    "last_page": 8
  }
}

You can also filter by category slug, search by keyword, or fetch a single post by slug:

// Filter by category
const headlessPosts = await fetch('/api/v1/posts?category=headless-cms');

// Single post by slug
const post = await fetch('/api/v1/posts/getting-started-headless-cms');

// Search
const results = await fetch('/api/v1/search?q=content+api');

UnfoldCMS's public read endpoints — /api/v1/posts, /api/v1/pages, /api/v1/categories, /api/v1/search, /api/v1/menus, /api/v1/settings — require no authentication. That's by design: your public content should be fetchable by your build tool, your CI pipeline, or your client-side JavaScript without a token dance.

Write operations use Sanctum token auth. Rate limit on the API throttle is 60 requests per minute — high enough for real apps, low enough to block abuse.

Outgoing webhooks are HMAC-signed. When a post publishes, your configured URL gets a POST with a signature header you can verify against your secret. That way you can safely trigger a site rebuild or a cache purge without worrying about spoofed requests.

Should You Use a Content API Today?

If you're building a single website that doesn't need to serve any other front-end, a traditional CMS is fine. The added complexity of an API layer isn't worth it.

But if any of these are true, a content API is probably the right move:

• You're building in Next.js, Astro, SvelteKit, or any non-PHP framework
• You have (or plan to have) a mobile app that needs the same content
• Your editors and your developers are on different cycles — editors shouldn't need a deploy to publish
• You want to serve the same content across multiple sites or brands
• You want to pre-render pages at build time for speed and SEO

For a full breakdown of when headless makes sense (and when it doesn't), the complete guide to headless CMS covers the trade-offs without the marketing spin.

FAQ

What is a content API in simple terms?

A content API is a URL your CMS exposes that returns your content as JSON. You call it from your app, it returns posts or pages or settings, and you render that data however you like. The CMS handles editing. The API handles distribution. Your front-end handles display.

Do I need GraphQL for a content API?

No. REST is the most common format for content APIs and is easier to work with for most teams. You make a GET request to a URL, you get JSON. GraphQL gives you more flexibility over which fields are returned, but it requires a query language and more setup. Start with REST.

What's the difference between a content API and a headless CMS?

A headless CMS is a CMS that exposes a content API instead of (or in addition to) rendering its own front-end. The content API is the mechanism. The headless CMS is the product that provides it. You can read more about the architecture in What Is a Headless CMS?.

How does authentication work with a content API?

Most content APIs split into two tiers: public read endpoints that require no auth (so your build tool can fetch freely) and write endpoints that require a token. For UnfoldCMS, public read endpoints use no auth and write endpoints use Sanctum tokens. Rate limits apply on both.

Can I use a content API with a static site generator?

Yes — this is one of the most common patterns. Astro, Next.js, SvelteKit, and Hugo all support fetching from a content API at build time. The site generator calls your API, gets the data, renders HTML files, and deploys them as static files. No CMS involved at runtime.

Try It Yourself

UnfoldCMS ships a full REST API out of the box — 42 endpoints, public read access with no auth required, Sanctum tokens for writes, and HMAC-signed webhooks for cache invalidation. No plugin to install. No third-party service to subscribe to.

You can browse the endpoint reference in the docs or see how the full feature set fits together on the features page. The API is live on any UnfoldCMS install — you can test it with a single curl command on your local setup before you build anything.

Related: What Is a Headless CMS? · Headless CMS Architecture Explained · API-First CMS: REST vs GraphQL