Skip to main content
GET
Read the credit balance this API key can spend
Returns what the calling credential — this API key or OAuth connection — can spend right now, alongside the organization-wide totals it is derived from. Requires the usage.read scope. For rates, see Pricing.

Credential-spendable vs organization-wide

The response carries two kinds of number. available and spendable_plan_credits answer “what can this credential spend”; plan_credits and topup_credits are organization-wide balances. Three relations always hold:
  • available == spendable_plan_credits + topup_credits
  • spendable_plan_credits <= plan_credits
  • for an organization with no active teams, spendable_plan_credits == plan_credits
If your organization has no teams, nothing changed for you. scope.type is org, spendable_plan_credits equals plan_credits, and available is still the plan pool plus top-ups.

The budget regime (scope)

An organization can reserve parts of its monthly plan pool as per-team budgets, and every API key can be assigned to a team. A credential then spends from exactly one bucket, and only that bucket’s headroom is available to it — which is why available can be lower than the organization-wide plan_credits. scope.team names the team the credential is bound to, or is null when it is bound to none. scope.remaining is budget - used, floored at 0. A team-bound key whose budget is the binding constraint:
Response
The organization still has 8031 plan credits, but the Marketing budget has 1200 left, so this key can only spend 1200 of them — plus the 250 budget-exempt top-up credits, for 1450 in total.

Predicting and diagnosing a 402

available is the predictor. A job whose estimated_credits is at most available is not refused with an insufficient-credit 402, and conversely such a 402 means the estimate exceeded available — on either number, the credential’s, not the organization’s. One exception: an operational failure inside the deduction itself (for example a degraded balance lookup) is reported as the generic insufficient_credits whatever the regime, without proving anything about available — a plain insufficient_credits where you expected a team-aware code can therefore be transient; retry before treating it as an exhausted balance.
The prediction holds only as long as the credit and budget state does not change between the read and the submit. Another credential of the same organization spending, a top-up lot expiring, a subscription change, a team budget being edited, or a key being reassigned to a different team can all move available — and even change scope.type and therefore which error code you get — without any spend of your own. subscription_inactive is a separate 402, unrelated to this comparison.
When a submit is refused, scope explains it:
  • scope.type names the budget regime, which is what selects the error code (barring the operational-failure fallback above) — see the table above. It does not tell you which balance ran out: a key under the team regime gets insufficient_team_credits even when the organization’s plan pool, and not the team budget, is what was exhausted.
  • To find the actual bottleneck under a capped regime (team or unallocated), compare plan_credits with scope.remaining — the smaller one caps spendable_plan_credits. Under org, scope.remaining is null and plan_credits is the only possible bottleneck.
  • remaining: 0 means that bucket is fully spent for the current period. It is not a precondition of the error: a bucket with remaining: 100 and no top-ups still refuses a job costing 200.
So a key with no team, in an organization whose plan pool is fully allocated to teams, reports available: 0 with scope.type: "unallocated" and remaining: 0 — every submit that costs credits will be refused with insufficient_unallocated_credits until a budget is lowered, the key is assigned to a team with headroom, or top-ups are purchased. See Errors for how to resolve each code.

Authorizations

Authorization
string
header
required

Organization API key as a bearer token: Authorization: Bearer samsa_sk_....

Response

Successful Response

GET /credits body — what the CALLING credential can spend (ADR §10, SAM-1029).

Two kinds of number:

  • available / spendable_plan_credits answer "what can THIS API key or OAuth connection spend right now" — capped by its team budget bucket (scope), so a job estimated at or below available is not rejected with insufficient_team_credits / insufficient_unallocated_credits.
  • plan_credits / topup_credits are the ORGANIZATION-wide balances.

All amounts are balances (not allocations), and available == spendable_plan_credits + topup_credits always holds, as does spendable_plan_credits <= plan_credits (they are equal whenever no team budget applies).

available
integer
required

Total credits the calling credential can spend right now — the sum of spendable_plan_credits and topup_credits. Capped by the credential's team budget bucket (see scope), so it can be lower than the organization-wide plan_credits.

Example:

1450

spendable_plan_credits
integer
required

Plan-pool credits the calling credential can spend right now: plan_credits capped by scope.remaining. Equal to plan_credits when no team budget applies.

Example:

1200

plan_credits
integer
required

The ORGANIZATION's remaining monthly subscription-pool credits — not necessarily all spendable by this credential (see spendable_plan_credits). 0 when the plan pool is exhausted or the subscription is canceled and past its period end (top-up credits stay spendable).

Example:

1200

topup_credits
integer
required

Remaining credits from valid (non-expired) top-up purchases. Top-ups are exempt from team budgets, so they are always fully spendable by any credential of the organization.

Example:

250

period
BillingPeriod · object
required

The org subscription's current billing-period bounds (ISO-8601).

scope
PublicCreditsScope · object
required

The credit bucket the calling credential spends from (SAM-1029).

Organizations can reserve parts of their monthly plan pool for teams. A credential (API key or OAuth connection) spends from exactly ONE bucket, and only that bucket's headroom is available to it — which is why available can be lower than the organization-wide plan_credits. The shortfall rule is cost > available (spendable_plan_credits + topup_credits): a submit is refused with an insufficient-credit 402 when the deduction, re-evaluating the same numbers at execution time, finds the estimated cost above availableinsufficient_credits under the uncapped org regime, insufficient_team_credits under team, and insufficient_unallocated_credits under unallocated (operational failures inside the deduction fall back to the generic insufficient_credits, whatever the regime). This response is a point-in-time snapshot, not a reservation: concurrent spends, top-up lots expiring, a canceled subscription's period ending, or a degraded balance lookup can make the deduction-time numbers differ from the ones reported here, and other checks can reject a request regardless of credits. type names the budget regime and selects which of those codes a balance shortfall raises — it does not say which balance ran out: under a capped regime the smaller of plan_credits and remaining limits spendable_plan_credits. remaining: 0 means this bucket has no plan-pool headroom left for the current period (spent down, or never allocated any); it is NOT a precondition of the error — a bucket with remaining: 100 and no top-ups still refuses a job costing 200.