Skip to main content
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-Key that already owns a run is never refused with 402. It returns the stored run.
Every new account gets $5 of credit (5,000,000 micros) once its email address is verified, one grant per email address.

How to fix

  1. Check the balance with GET /v1/billing (needs billing_read). balance_micros is credited minus spent minus held, and can be negative.
  2. Add credit: on the Billing page, or with POST /v1/billing/checkout and an amount_micros from 5to5 to 1,000. The credit arrives once the payment succeeds.
  3. 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.
  4. Retry the run once balance_micros is at least 20,000. The first attempt was refused before a run existed, so reuse the same Idempotency-Key.
Do not retry in a tight loop: until credit arrives, every attempt gets the same 402.

Example

Handling the 402: report the balance, keep the key, and retry after credit arrives. The balance check needs a key with billing_read.