Lire la réponse complète
Pour un statut d’échec, conservez le code HTTP, les en-têtes, le corps de l’erreur et l’ID de requête après avoir supprimé les secrets. Ils permettent de distinguer une requête non valide d’un refus d’accès ou d’un problème temporaire.
N’affichez pas une réponse brute du service comme unique message destiné à l’utilisateur : expliquez l’action tout en conservant les détails de diagnostic pour un opérateur.
curl --include --request POST https://cicora.ai/api/v1/chat/completions \
--header "Authorization: Bearer $CICORA_API_KEY" \
--header 'Content-Type: application/json' \
--data '{"model":"openai/gpt-5.6-sol","messages":[]}'Classer l’échec
- Une erreur 4xx exige généralement de corriger une clé, les données d’entrée ou l’accès.
- Une erreur 429 exige de respecter la fenêtre de limitation et d’éviter des tentatives répétées agressives.
- Les erreurs 5xx et les défaillances réseau nécessitent un nombre limité de nouvelles tentatives, avec temporisation exponentielle et variation aléatoire.
Réessayer en toute sécurité
Ne réessayez que les échecs temporaires et uniquement si l’opération est idempotente dans votre produit. Pour la génération, conservez un ID de requête client afin d’éviter une double facturation ou un artefact dupliqué.
En diffusion continue, distinguez une erreur survenue avant le premier delta d’une interruption après une sortie partielle : cette dernière ne peut pas être remplacée silencieusement par une nouvelle réponse.