code lisible
par machine, pas le message humain (les messages peuvent changer ; les codes sont
stables).
L’enveloppe d’erreur
Les réponses réussies ne contiennent jamais d’objet
error. Branche d’abord sur
le statut HTTP, puis sur error.code.Codes d’erreur
invalid_api_key
HTTP 401. Le header Authorization est manquant ou malformé, ou la clé est
inconnue, expirée ou révoquée — ou le créateur de la clé n’est plus membre de
l’organisation. Les clés expirées et inconnues sont intentionnellement
indistinguables.
Authorization: Bearer samsa_sk_…. Si la clé
a été révoquée ou a expiré, crées-en une nouvelle.
Ne réessaie pas — le résultat ne changera pas.
missing_scope
HTTP 403. La clé est valide mais n’a pas le scope
que le endpoint requiert. param vaut "scope" et le message nomme le scope
manquant.
insufficient_credits
HTTP 402. Le pool de credits dépensable de l’organisation (abonnement plus
top-ups valides) est en dessous du coût de l’action. Voir Tarification.
Si l’organisation a au moins une équipe active, l’API renvoie à la place les codes
liés aux équipes insufficient_team_credits ou
insufficient_unallocated_credits.
subscription_inactive
HTTP 402. L’organisation n’a aucun abonnement utilisable (aucun actif, en
période de grâce, ou détenant des top-ups dépensables). Distinct de
insufficient_credits, où un abonnement existe mais le pool est trop bas.
insufficient_team_credits
HTTP 402. Les organisations peuvent répartir leurs credits d’abonnement mensuels
en budgets par équipe, et chaque clé API peut être assignée à une équipe. Une clé
assignée à une équipe avec budget dépense depuis le bucket mensuel de cette équipe ;
tout ce qui n’est alloué à aucun budget d’équipe forme le pool non alloué de
l’organisation. Les top-ups achetés sont exemptés des budgets et restent
disponibles pour couvrir le reste. Ce code survient quand le budget restant de l’équipe pour la
période de facturation en cours, plus les top-ups, est en dessous du coût de
l’action.
insufficient_unallocated_credits
HTTP 402. La clé n’est pas assignée à une équipe avec budget (non assignée, ou
son équipe n’a pas de budget), elle dépense donc depuis le pool non alloué de
l’organisation — les credits d’abonnement mensuels restants après soustraction des
budgets de toutes les équipes actives. Ce code survient quand ce pool, plus les top-ups exemptés
des budgets, est en dessous du coût de l’action. Les organisations sans équipe
active ne voient jamais les deux codes liés aux équipes — elles reçoivent le simple
insufficient_credits à la place.
not_found
HTTP 404. L’id est inconnu, ou il appartient à une autre organisation. Les deux
cas sont indistinguables par conception, donc l’existence n’est jamais divulguée
entre organisations.
validation_error
HTTP 422. Le corps de la requête ou un paramètre a échoué à la validation.
param nomme le champ fautif ; message explique la contrainte.
message et param, puis renvoie-la.
C’est une erreur client — réessayer la même requête échouera de façon identique.
rate_limited
HTTP 429. La clé a dépassé sa fenêtre de rate de requêtes par clé. La réponse
porte les headers Retry-After et X-RateLimit-*. Voir Rate limits.
Retry-After. Utilise un
backoff exponentiel pour des 429 répétés.
too_many_active_jobs
HTTP 429. L’organisation a atteint son plafond de jobs concurrents en cours. Le
message inclut le compte actuel et la limite, et un header Retry-After est défini.
GET ou utilise un webhook) avant
d’en soumettre d’autres, puis réessaie après Retry-After.
internal_error
HTTP 500. Une erreur inattendue du côté de Samsa. La réponse ne divulgue jamais
de détails internes — le request_id est ton point d’entrée pour le support.
request_id.
Utiliser request_id pour le support
Chaque erreur (et chaque succès) porte un request_id, aussi renvoyé dans le
header de réponse X-Request-ID. Il relie ton erreur côté client, le header de
réponse et les logs serveur de Samsa à une même requête. Log-le, et cite-le quand
tu contactes support@samsa.ai — c’est le moyen le plus
rapide pour nous de retrouver exactement ce qui s’est passé.

