Get Account Balance

GET/v1/billing/balance

Choose the scope and credential first

  • One key's usage/budget: call GET /v1/key with that inference API key. Read usage, limit_remaining, and limit_reset. This is a key spending budget, not the enterprise wallet or credit balance.
  • Enterprise wallet and credit: call GET /enterprise/v1/billing/balance with a MANAGEMENT key scoped only to tenant:billing:read. Inference and PROVISIONING keys cannot use it.
  • Account charges/request reconciliation: existing GET /v1/billing and GET /v1/billing/requests/{request_id} use an inference key or signed-in JWT. Management keys cannot call these /v1 endpoints. Recorded charges and remaining balance are different metrics.
  • Legacy account balance: GET /v1/billing/balance remains compatible and reports account funds, not the calling key's remaining budget. Prefer the Enterprise endpoint for new enterprise balance monitoring.

Enterprise API guide · Get enterprise balance

Postpaid funding semantics

All amounts are USD. Under POSTPAY, positive wallet top-up funds are spent first and the remainder uses enterprise credit. Promotional Credit/vouchers are neither spent nor included in the total.

  • credit_limit_usd: approved credit limit.
  • current_exposure_usd: credit used in the current open billing period.
  • credit_remaining_usd: max(credit_limit_usd - current_exposure_usd, 0).
  • credit_available: remaining enterprise credit under POSTPAY; available vouchers under PREPAY. These meanings are different.
  • total_spendable: max(wallet_available, 0) + credit_remaining_usd for POSTPAY; the existing wallet_available + credit_available for PREPAY.

Historical unpaid invoices are not deducted from remaining credit a second time. Balances are snapshots of recorded billing data, not real-time reservations. Exhausted credit, key limits, account spend protection or other policies can still reject requests. Exhausted credit blocks new POSTPAY calls even if wallet funds remain, so the total is not a guarantee of callable capacity.

Authentication

Use an inference API key or signed-in JWT. MANAGEMENT / PROVISIONING keys cannot use this path. Enterprise members resolve both wallet and credit to the enterprise billing owner.

Response

codeinteger

200 on success

dataobject
data.currencystring

Currency: usd

data.payment_modestring

PREPAY or POSTPAY

data.wallet_availablenumber

Available wallet balance, possibly negative

data.wallet_frozennumber

Frozen wallet balance

data.credit_availablenumber

PREPAY vouchers; POSTPAY remaining credit

data.credit_limit_usdnumber

Credit limit; 0 for PREPAY

data.credit_remaining_usdnumber

Remaining credit; 0 for PREPAY

data.current_exposure_usdnumber

Open-period credit usage; 0 for PREPAY

data.total_spendablenumber

Account total according to payment mode

data.checked_atstring

UTC ISO-8601 observation time

Solicitar

Shell
1curl "https://api.token360.ai/v1/billing/balance" \
2  -H "Authorization: Bearer $INFERENCE_API_KEY"

Respuesta

JSON
1{
2  "code": 200,
3  "msg": "success",
4  "data": {
5    "currency": "usd",
6    "payment_mode": "POSTPAY",
7    "wallet_available": 20,
8    "wallet_frozen": 0,
9    "credit_available": 70,
10    "credit_limit_usd": 100,
11    "credit_remaining_usd": 70,
12    "current_exposure_usd": 30,
13    "total_spendable": 90,
14    "checked_at": "2026-11-03T00:00:00Z"
15  }
16}

The legacy endpoint uses service_code / trace_id error fields.

¿Ha sido de ayuda?