How credits work
Every billable API call debits micro-credits from a project budget. Micro-credits are the unit the ledger uses; the dashboard formats them as a fiat amount in the account's currency on display.
What's billed
A call is billed when the action ran and produced an answer —
that is, when the response envelope is HTTP 200 with ok: true.
This includes empty results (e.g. identify returning zero
candidates, detect returning zero faces) — the model ran, the
answer was "nothing here."
Per-action prices vary. The cost is fixed at the time of the call and shown on the row that lands in the ledger.
What's not billed
Anything that fails before the model runs:
UNAUTHORIZED— key missing, unknown, revoked, or expired.FORBIDDEN— key valid but lacks permission for this action / project.PAYMENT_REQUIRED— project budget exhausted.RATE_LIMITED— burst or sustained limit hit at the gate.PAYLOAD_TOO_LARGE— image exceeded the size cap.INVALID_REQUEST— bad parameters (missing required, wrong type, out of range).NO_FACE_DETECTED,MULTIPLE_FACES_DETECTED,SUBJECT_NOT_FOUND,CONFLICT— input-quality codes; no model work was billable.IDEMPOTENCY_REPLAY— duplicaterequestIdwithin the dedup window; the original row was already billed.
The full mapping of code to billed/not-billed is in Errors.
Where credits sit
Credits live in two places, both visible on the dashboard:
- Tenant wallet — micro-credits held at the account level. Not directly spendable by API calls.
- Project budget — micro-credits moved from the wallet into a specific project. This is what calls actually drain.
The dashboard's balance card shows both totals; each project row carries a usage bar of the form current / capacity.
See Budget allocation for the mechanics of moving micro-credits from the wallet into a project.