Company scoping
A key authenticates at the tenant level, but most resources belong to a company. The effective company for a request is resolved with a layered fallback.
Resolution order
- The
X-Company-Idrequest header (highest precedence). - The key's
default_company_id, if one is configured on the key. - Your tenant's single active default company.
curl https://your-app.example.com/api/v1/customers \
-H "Authorization: Bearer sk_live_PUBLICID.SECRET" \
-H "X-Company-Id: 0190abcd-1234-7000-8000-000000000000"When no valid company resolves
If none of the three sources yields a company, or the one named by the header (or the key default) is
not an active company in your tenant (unknown, archived, or belonging to another tenant), the
request fails with 422 and the invalid_company code:
{
"error": {
"code": "invalid_company",
"message": "company … is not an active company in this tenant",
"requestId": "0190abcd-1234-7000-8000-000000000000"
}
}Company is part of the idempotency fingerprint
The resolved company is folded into the request fingerprint for Idempotency.
The same Idempotency-Key reused against a different effective company is treated as a different
request (an idempotency_conflict), never replayed across companies.