CRM MCP server
The same operations as MCP tools, generated rather than hand-written, so the two cannot describe different products.
Read it →GET/v1/openapi.json
A headless CRM, and a screen that proves it
The data model, the permissions and the timeline are reachable over REST and MCP with nothing rendered in front of them. The dashboard is a client of that API, not a privileged layer above it — which is the only way to know the head really did come off.
What a headless CRM is
The short version, then the version that matters — what the term means in general, and what it turns out to mean when a product is actually built that way.
The definition everyone uses
The records, the business rules and the permissions are exposed as an interface any client can call, and the user interface is one such client. Nothing lives behind the screen. Removing the screen removes no capability.
How you can tell
Ask what happens to a feature when the browser is gone. In a bundled CRM the answer is a support ticket. Here it is nothing: the dashboard reads the same schema, calls the same operations and gets the same errors your own client does.
Bundled against decoupled
Most CRMs have an API. That is not the same claim. The question is whether the interface is a description of the product or an export from it.
What the API covers
A bundled CRMThe objects worth syncing. Newer screens land months ahead of the endpoints behind them.
Agent Native CRMEvery operation the product has, documented in one OpenAPI document served without credentials at /v1/openapi.json.
Where the rules live
A bundled CRMPartly in the API, partly in form validation the API never sees. Two clients, two behaviours.
Agent Native CRMIn the API. Contact refusal, task claiming and stage moves are refused at the same place for every caller, dashboard included.
Custom data
A bundled CRMA custom-fields table, queried differently from the standard ones and missing from half the filters.
Agent Native CRMA real column on a real table. Filters, views, activities and tasks treat it exactly like a standard field.
Integrating a new client
A bundled CRMAn SDK per language, a webhook catalogue, and a mapping layer you maintain.
Agent Native CRMOne skill file, one OpenAPI document, and an MCP server generated from the same operation table.
What you own
A bundled CRMThe data, once you have exported it. The shape of it belongs to the vendor.
Agent Native CRMThe shape too. The objects, fields, stages and vocabulary in a workspace were written into it through the API.
What that looks like in calls
Every route named below is one this API serves — a test reads them back against the operation table and fails on anything invented. Read them in order and you have the argument on this page without the prose around it.
One document describes the whole surface
98 operations across 68 paths, generated from the same table that registers the routes. A contract test fails the build if the router serves something the document does not describe, or describes something it does not serve, so the two cannot drift apart quietly.
- GET /v1/openapi.json
- GET /v1/skill
The schema is data, not a settings screen
Read the model, then change it over the same interface. Objects get their own tables and their own natural keys, and behave like core objects for activities, tasks, lists and views. Standard fields can be hidden; nothing is destroyed.
- GET /v1/schema
- POST /v1/schema/objects
- PATCH /v1/schema/fields/{id}
Reading is a saved query, not a screen
A view is filters, a sort and an optional grouping, stored as data and rendered by the dashboard. Your client can create one, read its rows, and get the group counts computed across the whole filtered set rather than the page it is holding.
- POST /v1/views
- GET /v1/views/{id}/records
- GET /v1/views
Access is a first-class object too
Principals, roles and keys are created and revoked over the API, which is what lets a client provision its own callers. A key is returned once and stored as a salted hash, so a lost key is re-keyed rather than looked up.
- POST /v1/principals
- POST /v1/principals/{id}/keys
- DELETE /v1/principals/{id}/keys/{key_id}
GET/v1/activities
Take the screen away and nothing stops working. That is the test.
Where a person still decides
None of these is a setting somebody switches on. Most are enforced by the API itself; the rest are enforced by the fact that the work sits in a queue until somebody takes it.
The dashboard is not a privileged client
It authenticates as a principal, calls the documented operations and reads the same errors. When the API refuses something, the screen has no way around it — which means the guarantees on this page hold for every caller rather than for the ones we remembered.
Errors are a small, closed vocabulary
Nine codes cover everything a caller can meet, each with a message and details naming what was wrong. A client can branch on them instead of matching strings, and a 409 tells you whether to retry or move on.
Nothing is metered on the way in
API calls are never rate limited and agents are never counted as seats. Plans cap stored records and activities, and GET /v1/usage reports where a workspace stands — so building against this does not get more expensive the more carefully you build.
Ids sort, cursors continue
Every id is a ULID, so ids order by creation time without a second column. Lists answer with data and a next_cursor, capped at 200 a page. Pagination is the same shape on every collection in the product.
GET/v1/openapi.json
What you get back
Not a diagram of the architecture — the actual shape of the response the rest of this page is built on. Nothing in it was configured in a settings screen; every part of it is readable and writable over the same API.
GET /v1/openapi.json
- openapi
- 3.1.0, served without credentials so a client can read it before it has a key
- paths
- 68, covering records, activities, tasks, deals, lists, views, schema and principals
- operations
- 98, each with a stable operationId that names the MCP tool generated from it
- securitySchemes
- bearerAuth. One header, one key, no OAuth dance to implement
- errors
- The same nine codes on every operation, with details naming the offending field
What this does not do
Said plainly, because each of these is a thing a product described this way is usually assumed to do, and an agent that assumes it will write code that never runs.
Headless does not mean unfinished
There is a dashboard, and it is the whole product rather than an admin panel: records, board, tasks, schema, principals and billing. It exists because the people supervising agents need somewhere to look, and it is built the way any other client would be.
No webhooks yet
Reads are pull. A client that wants to know what changed polls activities with a since filter and gets an append-only stream it can resume from. Push is a reasonable thing to want and it is not built; asking for it is a feature request, not a setting.
No integration catalogue, and no sending
There is no marketplace, no connector directory and no iPaaS layer. Anything that reaches another system reaches it from your side, holding its own credentials — which is also why this product does not send email or messages. A decoupled CRM decouples that too.
Questions people ask before they build on it
Answered here rather than in a call, and answered the way they would be answered in a call.
What is a headless CRM?
A CRM in which the data model, workflows and permissions are decoupled from the user interface and exposed over an interface any client can call. The screen becomes one consumer among several — an agent, a script, a bot or a custom app can do everything it can do.
Is a headless CRM the same as an API-first CRM?
They overlap. API-first describes how the product was built: the interface was designed before the screens. Headless describes what you get: no capability that only exists behind a UI. This product is both, and the OpenAPI document is how you check the second claim rather than take it.
Does a headless CRM come with a user interface?
This one does. Headless is a statement about where the capability lives, not about whether anything is rendered. The dashboard here is a client of the public API and has no route of its own into the data.
Can I build my own front end on it?
Yes. Read the OpenAPI document, issue a key to a principal, and call the same operations the dashboard calls. Saved views exist precisely so a client can render a list the workspace defined rather than hard-coding its own.
How do I get notified when something changes?
By reading the timeline. Activities are append-only and filterable by type, actor and a since timestamp, so a client resumes from the last one it saw. There are no outbound webhooks today.
Where to read next
The same product from a different angle. None of these repeats this page; each answers a question this one deliberately leaves alone.
CRM for developers
The same surface argued for the engineer holding it: keys you issue from code, a schema you migrate, and no SDK to keep in step.
Read it →Agentic CRM
The category argument, and the comparison with the CRM you already run.
Read it →Start with an empty workspace
An agent can create one with no key, no invitation and no human, and shape it through the same API you are about to hand it. Your API calls are never rate limited and agents are never counted.