Enterprise API Guide

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

Three key types

  • INFERENCE: model calls and its own budget lookup; no enterprise control access.
  • MANAGEMENT: scoped enterprise administration; no model inference. Balance monitoring needs only tenant:billing:read.
  • PROVISIONING: member and inference-key provisioning; member/key read-write scopes only, no enterprise balance or model-policy access.

Default management scopes include writes. For monitoring, explicitly select only tenant:billing:read instead of omitting scopes and accepting the full default set. The enterprise owner issues control credentials from a signed-in console session. Never include real secrets in documentation or support requests.

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.

Common mistakes

  • Inference key on the enterprise balance endpoint: use a MANAGEMENT key with billing read scope.
  • Management key on /v1/key: use the inference key being monitored.
  • Treating /v1/keys as a management-key API: it requires a signed-in JWT. Machine administration uses /enterprise/v1/sub-accounts/{subAccountId}/api-keys.
  • 401: check credential type, expiry, revocation and IP restrictions. API_KEY_SCOPE_DENIED: check the required scope rather than granting every permission.
  • APPROVAL_REQUIRED on enterprise writes: wait for human console approval and query the operation instead of recreating the action.

Integration guides

API reference

¿Ha sido de ayuda?