insufficient_credits means your organization does not have enough prepaid credit to start a run. Read this page when runs fail with a 402, and to decide whether your service should wait, alert or top up.
What happened
Route:POST /v1/runs.
Runs are paid from prepaid credit. Before a run starts, OpenType holds the run’s full per-request spend ceiling, at most 20,000 micro-USD ($0.02), against your balance until the run settles. A run that would take the available balance below zero is refused.
In practice, a run needs at least 20,000 micros of available credit to start, even though a typical decision run costs far less. Holds of runs still in flight count against the balance until they settle.
When the run is refused:
- The run and its hold are rolled back. Nothing was stored and nothing was charged.
- If auto-recharge is on, a card is saved and the balance is below your threshold, a charge to that card starts in the background.
- A replay of an
Idempotency-Keythat already owns a run is never refused with 402. It returns the stored run.
How to fix
- Check the balance with
GET /v1/billing(needsbilling_read).balance_microsis credited minus spent minus held, and can be negative. - Add credit: on the Billing page, or with
POST /v1/billing/checkoutand anamount_microsfrom 1,000. The credit arrives once the payment succeeds. - To avoid this in production, turn on auto-recharge. It tops up a saved card when the balance falls below your threshold, at most once per hour.
- Retry the run once
balance_microsis at least 20,000. The first attempt was refused before a run existed, so reuse the sameIdempotency-Key.
Example
billing_read.
Related
- Handling insufficient credits - the full pattern for production services.
- Credits and billing - balance, checkout and transactions.
- Auto-recharge - top up automatically before the balance runs out.
- Problem codes - every code, its status, and whether a retry can help.