Track credit consumption
Records usage and charges credit for it. The request carries no credit amount: send what happened, and the response’s charges carry what it priced to per metric, with totals as the sum.
Two shapes. A direct draw (account + events) charges against the account’s current credit. A settlement (reservation_id + events + close) closes a hold opened by /beta/credits/check, pricing each metric at the rate frozen when the hold opened. One payload can feed several credit-consuming metrics, and the draw is all-or-nothing: a refusal for one metric leaves every metric uncharged.
Events sent here are both metered and charged, so do not also send them to POST /beta/events. An event feeding no credit-consuming metric is rejected with 422 and belongs there instead. Identity comes from the Idempotency-Key, or from the events’ own unique_ids when no key is sent; reuse it when retrying. Insufficient credit returns 200 with allowed: false. 409 means the identity is bound to different work. Back off on 429.
Authorizations
API key authentication. Pass your API key as a Bearer token.
Headers
2026-04-01 A unique string used to ensure the request is processed exactly once. If you retry a request with the same idempotency key within 24 hours, the original response is returned without re-executing the operation.
255"ik_a1b2c3d4e5f6"
Body
The usage being recorded, up to 100 events. The amount charged is computed from these against whichever billable metrics count them; there is no credit amount in the request. On a settlement, an empty array with close: true releases the whole reservation, charging nothing, which is the recovery when work is abandoned.
Customer account ID or alias; direct-draw mode. Required unless reservation_id is set, where the account comes from the reservation.
"cust_abc123"
Whether this is the final call for the reservation. Required whenever reservation_id is set: there is no safe default, since true would end runs that meant to continue and false would leak reservations until they expire. The reservation also closes on its own if the events consume everything held. Not valid on a direct draw.
true
What to do when a settle cannot be fully covered by credit on a metric that stops at zero — either because it prices past the reservation's authorized hold, or because credit ran out before a late settle arrived. "reject" (the default) refuses the settle, burning and recording nothing. "record" burns what is available and reports the remainder in the charges' overflow, deliberately weakening a hard stop you configured. Reservation-settlement mode only. The refusal body's reason says which condition fired: adding credit resolves coverage_shortfall, but not envelope_exceeded, whose limit is the hold's size.
reject, record "record"
Reservation token returned by /check, to close it; reservation-settlement mode. Mutually exclusive with account. The events sent alongside are both metered and charged, so do not send them to /events as well.
"crt_abc123"
Response
Success
Whether the consumption was covered by available credit
Per-metric, per-ledger availability after this call — one entry per ledger, so a single-ledger payload returns one. Always an array, but empty when no availability was resolved to report, including every response served while the organization's gate is disabled. Check the length before indexing.
One entry per metric this call's events fed: quantity counted, credits priced, credit covered, overflow to cash, and the ledger that paid. Always an array, length 1 in the ordinary single-metric case.
Reservation this call settled or opened. Empty for a direct-consumption draw that opened no block.
"crt_abc123"
Whether the reservation is still open and can be settled again. False even on a close: false call whose events consumed everything held — there is no envelope left to keep open.
Credits still held by this reservation and available to later calls.
"0"
The charges summed. Derived from charges — the breakdown is authoritative.
The reservation's at-zero policy, reported when the envelope was exceeded.
"stop"
True when the events priced past the reservation's remaining hold and were recorded anyway because on_envelope_exceeded was record. Worth alarming on for a feature that stops at zero.
How many events this call recorded.
3
How many of those events at least one metric's filters counted toward a charge. A lower number than events_accepted means some events did not qualify, without exposing the filter itself.
2
True when the referenced reservation had expired and the work was re-resolved as a fresh consume
When the still-open reservation now expires. Each accepted call extends this, so a long run that reports as it goes never expires mid-flight. Absent once the reservation closes.
"2026-04-01T10:20:00Z"