Headless CRM
The architectural claim underneath this one, and the way to check it: ask what happens to a capability when you take the browser away.
Read it →GET/v1/skill
A CRM your code owns, not one you integrate with
This is not a page about hiring a CRM developer or becoming one. It is a CRM for developers: 98 REST operations, one OpenAPI document served without a key, an MCP server generated from the same table, and a data model your own code creates and changes at runtime.
Two different people type this into a search box
Two readers arrive here from the same query and only one of them wants what is on this page. Saying which is which at the top is cheaper for both of you than saying it at the bottom.
The reader this page is not for
A large share of this query is people looking to hire somebody who configures and customises a CRM, or people working out how to become that person. Both are real jobs, neither is what this page is about, and saying so at the top is cheaper than three scrolls of disappointment.
The reader this page is for
An engineer who needs a customer record their own code owns: create it, extend it, query it and move work through it from a program, with no browser session, no partner agreement and no client library lagging behind the product it wraps.
Building on a CRM, two ways
Nearly every CRM has an API and a developer portal. The difference shows up in the second week, when you need the endpoint behind a screen somebody shipped last quarter.
Getting a key
A CRM with a developer portalRegister an application, pick scopes, implement an OAuth flow, and wait for review before anything touches real data.
Agent Native CRMCreate a principal, issue a key, send it as a bearer token. The program that does this can also have created the workspace.
What the API covers
A CRM with a developer portalThe objects worth syncing. A feature that arrived on the screen this quarter reaches the API when somebody gets around to it.
Agent Native CRMThe whole product. The dashboard authenticates as a principal and calls the same operations you do, with no private route of its own.
Testing against it
A CRM with a developer portalA sandbox that drifts from production, a rate limit that makes a test suite slow, and a quota to plan releases around.
Agent Native CRMNo rate limit on any plan, so a suite is not a budget line. What a plan caps is how much a workspace stores, not how often you call.
Keeping up with the product
A CRM with a developer portalA changelog to read, an SDK to upgrade, and a mapping layer you own for as long as the integration lives.
Agent Native CRMOne operation table generates the router, the OpenAPI document and the MCP tools. A contract test fails the build if any two disagree.
What a model can do with it
A CRM with a developer portalWhatever you wrapped by hand. The model calls your code, and your code calls theirs, so the surface stops where your patience did.
Agent Native CRMEverything, over MCP, on the same key with the same permissions. 97 tools, one per operation, and no wrapper for you to maintain.
Who owns the shape
A CRM with a developer portalThe vendor. Their objects, their stage names, their vocabulary, and a settings screen where you agree with all three.
Agent Native CRMYou. Objects, fields, stages, activity types and status lists are written into a workspace through the API, by your code.
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.
Read the contract before you write a line
Two documents, neither behind a key. An OpenAPI 3.1 document generated from the same Zod schemas the handlers validate against, and a markdown file written for a model rather than about the product. Nothing in either is hand-written prose describing the API.
- GET /v1/openapi.json
- GET /v1/skill
- GET /v1/health
Provision your own callers
Principals, roles and keys are ordinary objects, so a program creates the identity it is about to use. A key comes back once and is stored as a salted hash; a lost one is re-keyed rather than looked up, and revoking one is a delete.
- POST /v1/principals
- POST /v1/principals/{id}/keys
- DELETE /v1/principals/{id}/keys/{key_id}
- POST /v1/principals/{id}/rekey
Migrate the schema from code
Add a field and it is a real column. Add an object and it gets its own table, its own natural key and the same activities, tasks, lists and views the core objects have. Every change emits a schema_changed activity with the diff, so a migration leaves a record of itself.
- POST /v1/schema/fields
- POST /v1/schema/objects
- PUT /v1/schema/stages
- PUT /v1/schema/status-lists/{name}
Query with saved views instead of a query language
A view is filters, a sort and an optional grouping, stored as data. Your client writes one, reads its rows, and gets group counts computed across the whole filtered set rather than the page it is holding. The dashboard renders that same object.
- POST /v1/views
- GET /v1/views/{id}/records
- PATCH /v1/views/{id}
Fail predictably
Nine error codes, each with a message and details naming what was wrong, so a client branches on a code rather than matching strings. Ids are ULIDs and sort by creation time. Every collection paginates with the same envelope, capped at two hundred a page.
- GET /v1/companies
- GET /v1/tasks
- POST /v1/tasks/{id}/claim
GET/v1/activities
An API you can finish reading in an afternoon is a product you can deploy on a Friday.
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.
A key never outranks the rules
Roles are enforced in the service layer, so a key with the wrong role gets a forbidden rather than a partial write. There is no administrative bypass and no elevated client, ours included, which is what makes the guarantees testable from outside.
Nothing you built against disappears underneath you
There is no destructive route on a record, and standard fields hide rather than drop. A schema element you retire soft-deletes and is purged after thirty days, so there is a rollback window by default rather than by policy.
Idempotency is the default, not a header
Companies key on their domain, people on their email or profile URL, list members on the pair. Replaying a batch after a timeout writes nothing the second time and answers created false, so retries never need a deduplication pass over the top.
The spec and the router cannot drift
A route that is served but not documented fails a contract test, and so does a documented route nobody serves. The description you fetch at build time is the one the handlers are running, because both are generated from one table.
GET/v1/skill
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/views/{id}/records
- view
- The saved query itself — filters, sort and group_by — so a client renders what the workspace defined
- data
- The rows. Fields your code added sit alongside standard ones, because they are columns on the same table
- groups
- Counts per group across the whole filtered set, not the page in hand. null when the view has no group_by
- next_cursor
- The envelope every collection uses. limit defaults to 50 and stops at 200
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.
No SDKs, and that is deliberate
There is no client library to fall behind the API, in any language. One OpenAPI document and one bearer header is the whole integration surface, and generating a typed client from it is a single command in whatever you already use.
Nothing pushes to you yet
There is no webhook and no event stream. A client that needs to know what changed polls the timeline with a since filter, which is resumable because activities are append-only and ids sort. Push is a feature request, and there is a route for filing one.
No connectors, and no sending
There is no marketplace, no connector directory and no automation layer. Anything that reaches another system reaches it from your side, holding your own credentials. This product delivers nothing: no email, no message and no call has ever left it.
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.
Is this page about hiring a CRM developer?
No, and the distinction matters enough to make first. This is a CRM for people who write software: the product is a REST API and an MCP server, the dashboard is one client of it, and the data model is something your code creates rather than something an administrator configures for you.
What makes a CRM developer-friendly?
A documented surface that covers the whole product, credentials you can issue from code, a data model you can extend at runtime, predictable errors, idempotent writes, and no rate limit that turns your test suite into a budget question. All six are checkable before you sign anything.
Do I have to use the dashboard?
No. It exists for the people supervising the work, and it holds no capability your client lacks. A workspace can be created, shaped, filled and operated entirely over the API, and the ones an agent starts on its own begin exactly that way.
How do I authenticate?
One header: an Authorization bearer key issued to a principal. There is no OAuth flow to implement and no app to register. Creating a workspace and spending a setup code are the two operations that take no key at all, because at that point you do not have one yet.
Can I put my own interface on it?
Yes. Read the OpenAPI document, issue a key, and call the operations the dashboard calls. Saved views exist so that a client renders the list a workspace actually defined, rather than hard-coding somebody else's idea of what a pipeline looks like.
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 MCP server
The same operations as MCP tools, generated rather than written, for the case where the client you are building is a model rather than a service.
Read it →For agents
The quickstart and the whole error vocabulary — four calls from having nothing but the domain to having written your first record.
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.