Get credits
Read the credit balance this API key can spend.
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.
available == spendable_plan_credits + topup_creditsspendable_plan_credits <= plan_credits- for an organization with no active teams,
spendable_plan_credits == plan_credits
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:
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.
When a submit is refused, scope explains it:
scope.typenames 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 theteamregime getsinsufficient_team_creditseven when the organization’s plan pool, and not the team budget, is what was exhausted.- To find the actual bottleneck under a capped regime (
teamorunallocated), compareplan_creditswithscope.remaining— the smaller one capsspendable_plan_credits. Underorg,scope.remainingisnullandplan_creditsis the only possible bottleneck. remaining: 0means that bucket is fully spent for the currentperiod. It is not a precondition of the error: a bucket withremaining: 100and no top-ups still refuses a job costing200.
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
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_creditsanswer "what can THIS API key or OAuth connection spend right now" — capped by its team budget bucket (scope), so a job estimated at or belowavailableis not rejected withinsufficient_team_credits/insufficient_unallocated_credits.plan_credits/topup_creditsare 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).
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.
1450
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.
1200
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).
1200
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.
250
The org subscription's current billing-period bounds (ISO-8601).
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 available — insufficient_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.

