Documentation
Check Endpoint
Call the single and batch decision endpoints with concrete request and response shapes from the local backend contracts.
Check Endpoint
The core authorization API is POST /v1/check.
Authentication
Send a project API key as a bearer token.
Authorization: Bearer <project-api-key>
Content-Type: application/json
If the API key is missing or invalid, the current auth middleware responds with plain text:
unauthorized
Single check request
{
"subject": "user:alice",
"feature": "billing",
"action": "read",
"tenant": "tenant_acme"
}
Single check response
Field rules
subjectis requiredfeatureis requiredactionis requiredtenantis optional, but if present it must not be an empty string
Fail-closed internal evaluation response:
{
"allowed": false,
"reason": "error"
}
Batch checks
Use POST /v1/check/batch when the subject and tenant are the same across several requested permissions.
{
"subject": "user:alice",
"tenant": "tenant_acme",
"checks": [
{ "feature": "billing", "action": "read" },
{ "feature": "billing", "action": "write" },
{ "feature": "reports", "action": "export" }
]
}
Batch response:
Operational notes
- Batch access is plan-gated in the backend
- Each batch item is billed as an individual decision
- Unknown JSON fields are rejected by strict decoding
- Invalid request bodies return a JSON
errorresponse POST /v1/checkreturns{ "allowed": false, "reason": "error" }when evaluation fails internallyPOST /v1/check/batchreturns{ "error": "..." }for request-level failures such as invalid bodies or plan-gated accessPOST /v1/check/batchkeeps200 OKfor per-item evaluation failures and sets the affectedresults[].reasontoerror- auth failures still return plain-text
unauthorized