Authorization header.
Token shape and scope
Every token is scoped to a single tenant and carries a set of capability scopes that gate what it can do. Issue each key with the narrowest set it needs:
A
* wildcard scope also exists — treat it like a root credential and
avoid it in production integrations.
Tokens are prefixed for hand-checking:
sk_live_...— production traffic.sk_sandbox_...— sandbox tenant.sk_test_...— local test fixtures (no real backend).
Token rotation
The platform supports overlapping tokens during a rotation window so there is never a moment when an operator’s automation is offline:- Generate a new token in the operator dashboard.
- Roll your services onto it (rolling deploy, blue-green, etc.).
- Wait until your observability shows zero traffic on the old token.
- Revoke the old token.
Sandbox vs. production
The sandbox uses a separate signing key so any proof pack you fetch
from sandbox cannot impersonate a production pack. The public half of
both keys is published at
docs.enfinitos.com/compliance/verification-keys.
Rate limits
Each tenant has a request quota set by its plan. The sandbox ships with a generous quota for evaluation; production quotas are finalised per plan at the April 2027 launch. When a quota is exhausted the API returns429 with a RATE_LIMITED error
and a Retry-After header. Responses also carry rate-limit headers so you
can track remaining quota, and the SDKs back off and surface a warning as
you approach the limit.
Errors
Errors use the sameok / error / message shape: ok is false,
error is a machine-readable code, and message is human-readable. An
unauthenticated request, for example, returns:
Other endpoints also return
BAD_REQUEST (400), VALIDATION_FAILED (422),
RESOURCE_NOT_FOUND (404), STATE_CONFLICT (409), PRECONDITION_FAILED
(412), RATE_LIMITED (429), and INTERNAL_ERROR (500).