A key that opens exactly what you scoped it to, and nothing else
Most business software treats its API as an export hatch — a way to get data out, bolted on late, documented in a PDF. Ours is the same permission system the application uses, which means a key can never do anything the person who created it could not, and you can see exactly what it may do before you hand it to a vendor.
A key is scoped, and the scope is real
You create a key in Settings, choose the named permissions it may use, and see the secret exactly once. What the key can do is the intersection of those scopes and what its creator was already allowed to do — so it narrows, it never widens.
- Scopes are chosen from the same permission list that governs people
- A key never inherits an administrator's bypass, whoever created it
- Set an expiry, revoke at any time, and see when a key was last used
A specification, not a list of endpoints in an email
An OpenAPI document describes the surface, so you can generate a client rather than hand-write requests. Send the key as an X-Api-Key header or as a bearer token — whichever your integration platform models natively.
- OpenAPI (Swagger) specification, versioned with the API
- X-Api-Key or Authorization: Bearer — both accepted
- Errors come back as coded envelopes, not prose to regex
And an MCP endpoint, so an assistant can read the live system
Separate from the REST API and more interesting: an MCP connection lets an AI assistant — Claude, ChatGPT, whatever you use — query the live system in plain language instead of being told about it second-hand. It reads under its own scoped credential, through the same permission and module checks as a person, and every call is audited.
- Connections managed in Settings: scoped, shown once, revocable
- The assistant is bound by the same permissions and modules as everyone else
- It can read, and it can propose a change — but only a person can commit one
What API & integrations runs on
Hold this on its own, or add the modules beside it when you want them — they share one login and one set of records. See the module library and pricing.
- Included with your account — no API module to buy
- CRM
- Inventory
- Field Service
- Finance
Questions buyers ask
What can an API key actually reach?
Endpoints that declare a permission, and only the ones your key is scoped for. That is deliberately narrower than "anything the user could do": if a key could call endpoints with no permission attached, the scopes you picked would be decorative. It also means the surface grows by deliberate decision rather than by accident, so ask us if something you need is not covered yet.
What happens if a key leaks?
Revoke it — the key stops working immediately, and it was never able to do more than its scopes allowed in the first place. Keys can also carry an expiry date, and a key can never be used to create or revoke keys, so a leaked key cannot mint a replacement for itself or hide by removing others.
Can an AI assistant change things in my system?
Not on its own, and that is the design rather than a gap. Reads run and are audited. A write is never committed by the assistant: the capability layer refuses to execute it and records it as a proposal, and a person approves or rejects it in the decision queue. Approving replays the action under the identity the AI acted for, and only if the approver holds the permission that write would require of a human doing it by hand. So an assistant can ASK for a change; only a person can make one. The MCP endpoint also sits behind the AI switch in your own settings: off until you turn it on.
Is there a sandbox, webhooks, or a rate limit I should design around?
No sandbox tenant, no outbound webhooks and no published rate limit today — and we would rather say that plainly than let "we have an API" imply them. Integrations poll rather than subscribe. If webhooks are what your integration needs, tell us: that is a build conversation, not a hidden setting.
Do you have client libraries?
Not hand-written ones. There is an OpenAPI specification, and generating a client from it in your language is a normal step in most stacks. We would rather ship an accurate spec than three SDKs that drift apart.
See it running
Create an account, or tell us how you work today and we'll show you what API & integrations looks like on your data.