Erreurs HTTP

Notre API suit un format d’erreur HTTP prévisible :

  • 400 - invalid_request_error : Il y a eu un problème avec le format ou le contenu de votre requête. Nous pouvons également utiliser ce type d’erreur pour d’autres codes d’état 4XX non listés ci-dessous.

  • 401 - authentication_error : Il y a un problème avec votre clé API.

  • 403 - permission_error : Votre clé API n’a pas la permission d’utiliser la ressource spécifiée.

  • 404 - not_found_error : La ressource demandée n’a pas été trouvée.

  • 413 - request_too_large : La requête dépasse le nombre maximum d’octets autorisés.

  • 429 - rate_limit_error : Votre compte a atteint une limite de débit.

  • 500 - api_error : Une erreur inattendue s’est produite dans les systèmes internes d’Anthropic.

  • 529 - overloaded_error : L’API d’Anthropic est temporairement surchargée.

    Les erreurs 529 peuvent survenir lorsque les API d’Anthropic connaissent un trafic élevé pour tous les utilisateurs. Dans de rares cas, si votre organisation connaît une forte augmentation d’utilisation, vous pourriez voir ce type d’erreur. Pour éviter les erreurs 529, augmentez progressivement votre trafic et maintenez des modèles d’utilisation cohérents.

Lors de la réception d’une réponse en streaming via SSE, il est possible qu’une erreur se produise après avoir retourné une réponse 200, auquel cas la gestion des erreurs ne suivrait pas ces mécanismes standard.

Formats d’erreur

Les erreurs sont toujours renvoyées au format JSON, avec un objet error de premier niveau qui inclut toujours une valeur type et message. Par exemple :

JSON
{
  "type": "error",
  "error": {
    "type": "not_found_error",
    "message": "The requested resource could not be found."
  }
}

Conformément à notre politique de versionnement, nous pouvons étendre les valeurs au sein de ces objets, et il est possible que les valeurs type évoluent au fil du temps.

ID de requête

Chaque réponse API inclut un en-tête unique request-id. Cet en-tête contient une valeur telle que req_018EeWyXxfu5pfWkrYcMdjWG. Lorsque vous contactez le support à propos d’une requête spécifique, veuillez inclure cet ID pour nous aider à résoudre rapidement votre problème.

Nos SDK officiels fournissent cette valeur comme propriété sur les objets de réponse de premier niveau, contenant la valeur de l’en-tête request-id :

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-4-20250514",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Hello, Claude"}
    ]
)
print(f"Request ID: {message._request_id}")

Requêtes longues

Nous vous encourageons vivement à utiliser l’API Messages en streaming ou l’API Message Batches pour les requêtes de longue durée, en particulier celles dépassant 10 minutes.

Nous ne recommandons pas de définir des valeurs max_tokens élevées sans utiliser notre API Messages en streaming ou API Message Batches :

  • Certains réseaux peuvent interrompre les connexions inactives après une période variable, ce qui peut entraîner l’échec ou l’expiration de la requête sans recevoir de réponse d’Anthropic.
  • Les réseaux diffèrent en fiabilité ; notre API Message Batches peut vous aider à gérer le risque de problèmes réseau en vous permettant d’interroger les résultats plutôt que d’exiger une connexion réseau ininterrompue.

Si vous construisez une intégration API directe, vous devez savoir que la configuration d’un keep-alive de socket TCP peut réduire l’impact des délais d’expiration de connexion inactive sur certains réseaux.

Nos SDK vérifieront que vos requêtes API Messages non-streaming ne devraient pas dépasser un délai d’expiration de 10 minutes et définiront également une option de socket pour le keep-alive TCP.