freeze -> consume / unfreeze flow when cost is unknown upfront.
This is the right choice for LLM inference, async tasks, and flows where final cost is only known after execution.
transaction_id is the unique ID for this charge transaction and stays the same across freeze, consume, and unfreeze.
Freeze
Reserve a maximum budget before starting work. After freezing, credits are no longer available to spend, but they have not been consumed yet.Freeze ParametersFreeze ResponseReturns
The unique identifier for this customer. The customer must already exist and have enough available credits to cover the freeze amount.
Unique ID for this charge transaction. Use the same value for the subsequent
consume or unfreeze call.Maximum credits to reserve. Must be greater than 0. Set this to the upper bound of expected cost.
Restrict the freeze to these wallet categories only. If omitted, the system may use any active credits. The same categories are used automatically during consume.
Transaction category for reporting. Examples:
TASK, ORDER, TOKEN_USAGE.A human-readable note for this freeze.
The transaction ID passed in the request.
Total credits reserved by this freeze.
Breakdown of which credit accounts were frozen. The system may freeze across multiple wallet categories.
true when the response was returned from a previous request with the same transaction_id.400 with insufficient balance if the user does not have enough available credits.If credit_types is provided during freeze, and the selected wallet categories do not have enough credits, the error message becomes insufficient balance in selected credit_types.Consume
Settle the actual cost after the task finishes. Any unused credits are returned automatically.Example: freeze Consume Response
100, finish with an actual cost of 73, and the remaining 27 is automatically returned.Consume ParametersThe same transaction ID used in the freeze step.
Actual credits to consume. If less than the frozen amount, the remainder is returned. Defaults to the full frozen amount if omitted.
Credits permanently consumed by this operation.
Unused frozen credits automatically returned to the available balance (
frozen_amount - actual_amount).Breakdown of which credit accounts were consumed.
ISO 8601 timestamp when consumption completed.
true when the response was returned from a previous request with the same transaction_id.Unfreeze (Cancel)
Release frozen credits without consuming. Use when the task is cancelled.Unfreeze Response
Total credits returned to the available balance.
Breakdown of which credit accounts were unfrozen.
ISO 8601 timestamp when the unfreeze completed.
true when the response was returned from a previous request with the same transaction_id.Wallet Categories and Consumption Order
- The system automatically freezes and consumes from all available credits.
- If
credit_typesis provided duringfreeze, only those wallet categories are eligible for this transaction. - Callers do not choose which wallet category to use.
- Credits that expire sooner are handled first; if expiry is the same, older accounts are handled first.
- Only credits that are currently active participate in freeze and consume. Credits that have not started yet or have already expired are ignored.
- Use the customer balance API to inspect remaining credits by
credit_type.
Idempotency
All three operations are idempotent ontransaction_id. Duplicate calls return the original result with is_idempotent_replay: true.
Verify the Result
- whether
balance.frozenincreases after freeze - whether
balance.usedincreases after consume - whether
balance.availablechanges as expected - which
accounts[].credit_typeentries were used
Error Format
All API errors return an HTTP error status and a structurederror object:
Human-readable description of the error.
High-level error category.
Stable machine-readable error code for programmatic handling.