What Spunto CMS is
A Notion-style workspace whose content is also served as a headless CMS over REST — the same rows, no export step.
Spunto CMS is a workspace you write in — lists of cards, a shared registry of typed properties, block-structured page bodies, saved views with filters and sorts — and an API that serves it.
There is no export step, and no publish pipeline that copies content somewhere
else. The rows a writer edits are the rows the API returns. When someone
changes a status in the interface, the next POST …/query returns the new
value, because there is only one place the value lives.
What that buys you
One model, two audiences
Editors get lists, cards and saved views. Consumers get a typed REST API over the same tables — filters, sorts, keyset pages.
A committed contract
The OpenAPI specification is generated from the routes, committed to the repository and served live. A TypeScript client is generated from it.
Writable by machines
An API key can create and update content. Scripts, agents and imports use the same routes the interface does — nothing is reserved for the UI.
Isolated per workspace
Every tenant is separated by Postgres row-level security, not by a WHERE
clause someone has to remember to write.
Two documentation surfaces
This site is the product documentation: what the objects are, how they relate, and how to work with them.
The API reference is a separate, generated surface. Every route, every parameter and every schema is described there, from the same specification the client library is generated from:
- API reference — the interactive Scalar reference.
/openapi.json— the raw specification.
The reference is generated, this site is written
Nothing here restates the parameter list of a route. When the two disagree, the reference is right: it comes from the code, this site comes from a human.
Where to start
If you want to see it work, go to the quickstart — sign in, create a list, read it back over the API in about ten minutes.
If you want to understand the model before touching it, start with collections and cards; the rest of the Concepts section builds on that one page.
If you are here to plug something in, the API section covers authentication, querying, writing and the event log.
And if you are deciding whether this fits at all, read what it does not do first. It is short, and it is honest.
What this is not
REST only. There is no GraphQL endpoint, and there will not be one — that is a settled decision, not a roadmap item.