Headless CMS: build a blog backend

A headless CMS stores and manages content, and leaves the website to you. Editors write in an admin interface. Your frontend, whether that's Next.js, a mobile app or a static site generator, reads the content as JSON over an API.

Anythink fits that shape without a separate product. Your content types are entities, the Anythink dashboard is the editing interface, and every entity already has a REST API. This page builds a small blog end to end: the content model, an editor workspace, a public read endpoint, a Next.js page that fetches it, and an optional rebuild when content changes. Each step shows the dashboard, the CLI and an AI assistant (MCP).

If you haven't used Anythink before, read Core concepts first.

What you'll build

• An articles entity: title, slug, body (rich text), cover image, status (draft or published) and publish date.
• An authors entity, linked from each article.
• An editor role with a short menu in the dashboard.
• A public API that returns published articles with no sign-in, plus public search.
• A Next.js page that lists and renders them.

Step 1: Model your content

Create authors first, so articles can point at it.

Mark the fields your public site needs as Searchable and Publicly Searchable (--searchable --public on the CLI). That's what step 3 uses, so it's easiest to set them now.

anythink entities create authors
anythink fields add authors name --type varchar --required --name-field --searchable --public

anythink entities create articles
anythink fields add articles title --type varchar --required --name-field --searchable --public
anythink fields add articles slug --type varchar --required --unique --indexed --searchable --public
anythink fields add articles body --type text --display rich-text --searchable --public
anythink fields add articles status --type varchar --display select --options "draft,published" --default draft --indexed --searchable --public
anythink fields add articles published_at --type timestamp --searchable --public
anythink fields add articles cover_image --type file --searchable --public
anythink fields add articles author --type many-to-one --target authors --on-delete "SET NULL" --searchable --public

Create two entities, authors and articles. authors has a required name field that is the name field. articles has a required title (name field), a required unique slug, a rich-text body, a file field called cover_image, a select field called status with draft and published and a default of draft, a timestamp called published_at, and a many-to-one author field pointing at authors. Make every field searchable and publicly searchable.

Step 2: Let editors write in the dashboard

The dashboard already gives you a grid and a form for every entity. What editors need is access to the right entities, and a sidebar that doesn't show them everything else. That takes two things: a role with permissions, and a menu assigned to that role.

anythink roles create editor --description "Writes and edits content"
anythink menus list
anythink menus add-item 12 articles --icon FileText
anythink menus add-item 12 authors --icon Users

Create a role called editor, then add articles and authors to the Editors menu with the FileText and Users icons.

Step 3: Publish content publicly

By default an entity's API needs a signed-in user or an API key. For a public website you want anonymous visitors to read published articles. Three pieces make that work.

• The entity's Public flag. A public entity can be read without credentials through the public endpoints.
• Public fields. A public endpoint returns only the fields marked Publicly Searchable. Every other field, body included if you left it off, is left out of the response. Mark only what a web page should show.
• A status filter. You choose which records to ask for. The endpoint returns every record of a public entity, so your frontend asks for status=published.

anythink entities update articles --public true
anythink entities update authors --public true

anythink fields list articles
anythink search query "*" --public --entities articles --limit 5

Make the articles entity public, then check what an anonymous visitor can read on it and list the public fields.

Read published articles

The public list endpoint takes no token. page and pageSize are required. Any other query parameter is a filter on that field.

GET /org/{project_id}/entities/articles/public/items?status=published&sortBy=published_at&sortDirection=desc&page=1&pageSize=20&fields=title,slug,published_at

{
  "items": [
    {
      "locked": false,
      "id": 1,
      "title": "Espresso guide",
      "slug": "espresso-guide",
      "published_at": "2026-10-01T09:00:00Z",
      "__name": "Espresso guide"
    }
  ],
  "page": 1,
  "page_size": 20,
  "total_items": 1,
  "total_pages": 1,
  "has_next_page": false,
  "has_previous_page": false,
  "retrieval_time": 143
}

Fetch one article by slug with the same endpoint, ?slug=espresso-guide&status=published&page=1&pageSize=1. GET /entities/{entity}/public/items/{id} fetches by id. For an entity that isn't public, both return 404. Filter operators such as GTE: and C: and the fields parameter work the same as on the signed-in list: see REST API reference.

Search published content

Public search finds articles by words in their publicly searchable fields. It needs no token.

GET /org/{project_id}/search/public?q=espresso&e=articles&fl=status%20%3D%20published

q is the search text, e limits it to the articles entity, and fl is a filter, here status = published, URL-encoded. The response has the same items and paging shape as above, and each item carries __entity and __url. Public search only matches and returns publicly searchable fields, so a field that is only Searchable stays hidden. Search covers filters, sorting, facets and ranking.

Step 4: Fetch it from a frontend

This is a minimal Next.js App Router example. The page is a Server Component, so the request runs on your server and the page can be cached.

// app/blog/page.tsx
const API = "https://api.my.anythink.cloud";
const PROJECT = process.env.ANYTHINK_PROJECT_ID;

type Article = { id: number; title: string; slug: string; published_at: string };

export default async function Blog() {
  const params = new URLSearchParams({
    status: "published",
    sortBy: "published_at",
    sortDirection: "desc",
    page: "1",
    pageSize: "20",
    fields: "title,slug,published_at",
  });

  const res = await fetch(
    `${API}/org/${PROJECT}/entities/articles/public/items?${params}`,
    { next: { revalidate: 60 } },
  );
  if (!res.ok) throw new Error(`Could not load articles (${res.status})`);
  const { items }: { items: Article[] } = await res.json();

  return (
    <ul>
      {items.map((a) => (
        <li key={a.id}>
          <a href={`/blog/${a.slug}`}>{a.title}</a>
        </li>
      ))}
    </ul>
  );
}

revalidate: 60 makes Next.js refresh the cached page at most once a minute, so new articles appear without a deploy. The page for one article is the same request with a slug filter:

// app/blog/[slug]/page.tsx
export default async function Article({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;
  const query = new URLSearchParams({ slug, status: "published", page: "1", pageSize: "1" });

  const res = await fetch(
    `${API}/org/${PROJECT}/entities/articles/public/items?${query}`,
    { next: { revalidate: 60 } },
  );
  const { items } = await res.json();
  if (!items.length) return <p>Not found.</p>;

  return (
    <article>
      <h1>{items[0].title}</h1>
      <div dangerouslySetInnerHTML={{ __html: items[0].body }} />
    </article>
  );
}

body is HTML written by your own editors. If anyone else can write to that field, sanitise it before rendering. The project id is in every API URL and isn't a secret. Keep it in an environment variable so staging and production sites can point at different projects. The same endpoint serves a mobile app or any other client that can make an HTTP request.

Step 5: Images and files

A File Upload field holds the files you attach to a record, such as cover_image. Files live in your project's storage, and editors upload them from the record form in the dashboard. To make the files on a field readable by visitors, tick Public in the field's file options. Public files can be fetched without signing in at GET /org/{project_id}/files/{id}/public, which redirects to the file's CDN address. Files that aren't public need a signed-in request.

Upload and manage files covers upload limits, accepted types, public and private files, and how files appear in API responses.

Step 6: Optional: rebuild the site when content changes

If your site is statically generated, a content change doesn't reach it until something rebuilds it. Most hosts give you a deploy hook: a URL that starts a build when you send a request to it. A workflow can call that URL when an article is published.

The trigger is an Event trigger on articles, set to run when a record is updated, with a filter so it only fires when status changes to published. The step is Call An API, which sends one HTTP request. Keep the hook URL in your project's secrets, because anyone who has it can trigger builds.

anythink secrets create DEPLOY_HOOK_URL --value "<your host's deploy hook URL>"

anythink workflows create rebuild-site --trigger Event --entity articles --event EntityUpdated \
  --filter '{"field":"status","op":"changed_to","value":"published"}' --enabled

anythink workflows step-add 42 call_deploy_hook --name "Call deploy hook" --action CallAnApi \
  --start --enabled \
  --params '{"url":"{{ $anythink.secrets.DEPLOY_HOOK_URL }}","method":"POST"}'

Create a workflow called rebuild-site that runs when an articles record is updated and its status changes to published. Add a Call An API step that POSTs to the URL in the DEPLOY_HOOK_URL secret, and enable the workflow.

What you get, and the limits

What you get

• Content types you model yourself, with typed fields, a rich-text editor and file uploads.
• A REST API for every entity, as soon as you create it, plus public read endpoints and public search.
• An editing interface in the Anythink dashboard, scoped by role and menu.
• Workflows that can call a deploy hook or any other URL when content changes.
• The same content for any frontend or app that can make an HTTP request.

Limits to plan around

• No draft model. status is a field you define and filter on. The public endpoint returns every record of a public entity unless your request filters, so anything you make public can be read by anyone. Keep content that must stay private, such as unpublished drafts with sensitive detail, in a separate entity that isn't public.
• No preview environments. There's no built-in preview URL for unpublished content. Build a preview route in your site that reads the signed-in API with a user token or a server-side API key.
• No locales. There's no built-in translation of content. Model languages yourself, for example with a locale field or a separate field per language.
• No version history or scheduled publishing. An edit replaces the previous value. You can build scheduling with a timed workflow.
• Rich text is HTML. It's stored and returned as HTML, so sanitise it if untrusted users can write to it.
• Public means readable by anyone. Only publicly searchable fields are returned, and search results lag a moment behind a save because indexing runs in the background.
• Menus are for dashboard pages. An editor's menu can show entity grids and other dashboard pages, not external links.

Next steps