The Content API

Reading the same content from somewhere else, over HTTP.

Everything a theme renders is also readable over HTTP — for a front end you host elsewhere, a mobile app, or a job that needs your content somewhere else.

It is read-only. Nothing is written through it.

The endpoints

GET /api/v1/collections/:collection/entries    entries in a collection
GET /api/v1/entries/:id                        one entry
GET /api/v1/taxonomies/:taxonomy/terms         terms in a taxonomy
GET /api/v1/terms/:id                          one term
GET /api/v1/globals/:handle                    a global's fields
GET /api/v1/navigation/:handle                 a navigation tree
GET /api/v1/assets/:id                         one asset
GET /api/v1/routes                             every public URL the site serves
GET /api/v1/schema                             the shape of the content
GET /api/v1/health                             whether the site is well

/api/v1/routes is the useful one for a static build: it tells you every page that exists, so a generator knows what to fetch.

Authorising a request

Create a token under API tokens in the control panel. Each one has its own scopes and its own expiry, so a token for one job cannot read everything forever.

curl -H "Authorization: Bearer $TOKEN" \
  https://example.com/api/v1/collections/guides/entries

A token is shown once, when it is created. Store it where your job can read it and nowhere else.

What comes back

Published content, in the same shape a view receives — so a field means the same thing in a template and in a JSON response, and you are not learning two content models.

Drafts and unpublished entries are never served, whatever the token’s scopes. The API is the public site in a different format, not a window into the control panel.

When to use it, and when not

Use it when something outside this application needs the content: another site, an app, a search index somewhere else, a static build.

Do not use it from your own theme. A theme asks for content through its query sidecar, which is faster, needs no token, and lets Nibble cache the page properly. Fetching your own API from your own view gives up all three.