Known gaps
Gaps in the product an integrator would otherwise find in the first hour, and where the plan to close each one lives.
This page lists what the API does not do today. Everything here is discoverable by anyone holding a key within about an hour, so reading it first is cheaper for both of us than finding it during an integration.
This page describes today and carries no dates. What comes next, by quarter, is on the roadmap.
There is no confidential escrow
An escrow is a public contract by construction, and nothing in the API hides it: there is no shielded settlement, no stealth addressing and no confidential deal mode. Anyone holding the contract address reads the amount, both sides and the full state history. What that means in practice, and the two levers you do have, are on escrow.
One provider adapter runs in production
Settlement is executed by your licensed providers, and exactly one provider adapter is live today. It is named under NDA on request, and will be listed publicly once that provider approves being named.
There is no policy object in the API
Policies are configured with us during onboarding, not through an endpoint. There is no /v1/policies, so a policy cannot be created, read, versioned or diffed over the API, and policy_version is stamped per organization rather than incrementing as rules change.
The practical consequence: do not build a workflow that reconstructs the rules that applied to an old decision from its policy_version. The field identifies the organization's policy set, not a revision of it.
The frequency rule is fixed
More than 10 requests from one agent in 60 seconds returns deny_velocity. That threshold is built into the engine. It is not a per-mandate setting, it is not configurable per environment, and it is not something a draft policy can change.
Reviews can be actioned but not read
POST /v1/reviews/{id}/approve and POST /v1/reviews/{id}/deny exist. GET /v1/reviews and GET /v1/reviews/{id} do not, and return 404.
A pending review is visible through the decision that created it and through the webhook event. Build your approval queue on those rather than on a review list endpoint.
Enforcement history is recorded but not readable
Switching mode with POST /v1/enforcement is written down, but no endpoint returns that history. What you can read today is GET /v1/enforcement for the current state, and the mode field stamped on every individual decision — which is enough to reconstruct what was in force when a given decision was made.
Fields that are stored but not enforced
arbiter on an escrow and escrow.required_above on a mandate are accepted, validated and persisted. Neither is currently read by the policy engine. They round-trip; they do not change any outcome.
There is no SDK, and no user management
The TypeScript SDK is private and issued at onboarding; the package name on npm is a reservation, not a library. There is no users, roles or permissions API — access is the two key classes described in authentication and nothing finer.