Skip to main content
Chaque erreur que l’API Samsa renvoie — pour n’importe quel endpoint, à n’importe quel statut — utilise une enveloppe JSON cohérente. Analyse le 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.
Comment gérer. Vérifie le header 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.
Comment gérer. Un admin modifie les scopes de la clé (ou émet une nouvelle clé) pour accorder le scope nommé. Ne réessaie pas sans changer la clé.

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.
Comment gérer. Recharge ou fais évoluer le plan de l’organisation dans l’app, puis réessaie. Rien n’a été facturé et aucun job n’a été créé.

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.
Comment gérer. Réactive la facturation de l’organisation dans l’app, puis réessaie.

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.
Comment gérer. Un admin de l’organisation peut augmenter le budget mensuel de l’équipe, assigner la clé à une autre équipe, ou acheter des top-ups (les top-ups ne sont pas limités par les budgets d’équipe). L’utilisation du budget se réinitialise aussi à la prochaine période de facturation. Rien n’a été facturé et aucun job n’a été créé.

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.
Comment gérer. Un admin de l’organisation peut libérer des credits non alloués en baissant les budgets d’équipe, assigner la clé à une équipe avec du budget disponible, faire évoluer le plan, ou acheter des top-ups. Rien n’a été facturé et aucun job n’a été créé.

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.
Comment gérer. Vérifie l’id, et que l’organisation de la clé possède bien la ressource. Ne réessaie pas.

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.
Comment gérer. Corrige la requête selon 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.
Comment gérer. Ralentis et réessaie après l’intervalle 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.
Comment gérer. Attends que les jobs en cours atteignent un statut terminal (interroge leur endpoint 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.
Comment gérer. Réessaie avec un backoff — les 500 sont souvent transitoires. Si cela persiste, contacte support@samsa.ai avec le 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é.
De nouveaux codes d’erreur peuvent être ajoutés au fil du temps (par exemple des codes additifs par endpoint). Traite un code non reconnu comme sa classe de statut HTTP, et branche toujours sur code plutôt que sur une correspondance de texte de message.