Obtenir les credits
Lis le solde de credits que cette clé API peut dépenser.
usage.read. Pour le détail des tarifs, voir Pricing.
Dépensable par le credential vs. total de l’organisation
La réponse porte deux sortes de nombres.available et spendable_plan_credits
répondent à « que peut dépenser ce credential » ; plan_credits et topup_credits
sont des soldes à l’échelle de l’organisation.
available == spendable_plan_credits + topup_creditsspendable_plan_credits <= plan_credits- pour une organisation sans équipe active,
spendable_plan_credits == plan_credits
scope.type vaut
org, spendable_plan_credits est égal à plan_credits, et available reste le pool
de plan plus les top-ups.Le régime de budget (scope)
Une organisation peut réserver des parties de son pool de plan mensuel en budgets par
équipe, et chaque clé API peut être affectée à une équipe. Un credential dépense alors
depuis exactement un bucket, et seule la marge de ce bucket lui est disponible — c’est
pourquoi available peut être inférieur aux plan_credits de l’organisation.
scope.team nomme l’équipe à laquelle le credential est affecté, ou vaut null quand il
n’en a aucune. scope.remaining vaut budget - used, plancher à 0.
Une clé liée à une équipe dont le budget est la contrainte active :
8031 credits de plan, mais il reste 1200 au budget Marketing :
cette clé ne peut donc dépenser que 1200 d’entre eux, plus les 250 credits de top-up
exemptés de budget, soit 1450 au total.
Prédire et diagnostiquer un 402
available est le prédicteur. Un job dont les estimated_credits sont au plus égaux
à available n’est pas refusé par un 402 de credits insuffisants, et inversement un tel
402 signifie que l’estimation a dépassé available — dans les deux cas le nombre du
credential, pas celui de l’organisation. Une exception : une défaillance
opérationnelle dans la déduction elle-même (par exemple une lecture de solde dégradée)
est signalée comme le code générique
insufficient_credits quel que soit le
régime, sans rien prouver sur available — un simple insufficient_credits là où tu
attendais un code lié aux équipes peut donc être transitoire ; réessaie avant de le
traiter comme un solde épuisé.
Quand une soumission est refusée, scope l’explique :
scope.typenomme le régime de budget, et c’est lui qui sélectionne le code d’erreur (hormis le repli opérationnel ci-dessus) — voir le tableau ci-dessus. Il ne dit pas quel solde s’est épuisé : une clé sous le régimeteamreçoitinsufficient_team_creditsmême quand c’est le pool de plan de l’organisation, et non le budget d’équipe, qui était épuisé.- Pour trouver la véritable contrainte sous un régime plafonné (
teamouunallocated), compareplan_creditsàscope.remaining— le plus petit des deux plafonnespendable_plan_credits. Sousorg,scope.remainingvautnulletplan_creditsest la seule contrainte possible. remaining: 0signifie que ce bucket est entièrement dépensé pour laperioden cours. Ce n’est pas une condition préalable de l’erreur : un bucket avecremaining: 100et sans top-ups refuse toujours un job coûtant200.
available: 0 avec scope.type: "unallocated" et
remaining: 0 — chaque soumission qui coûte des credits sera refusée avec
insufficient_unallocated_credits
jusqu’à ce qu’un budget soit abaissé, que la clé soit affectée à une équipe ayant de la
marge, ou que des top-ups soient achetés. Voir
Erreurs pour la résolution de chaque code.Autorisations
Organization API key as a bearer token: Authorization: Bearer samsa_sk_....
Réponse
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.

