Skip to main content
L’API Chariow utilise des codes de réponse HTTP conventionnels pour indiquer le succès ou l’échec.

Codes de statut HTTP

Format de réponse d’erreur

Erreurs courantes

Erreur de validation (422)

Se produit lorsque les données envoyées ne passent pas la validation :
Comment résoudre :
  • Vérifiez que tous les champs requis sont présents
  • Assurez-vous que les formats sont corrects (email, téléphone, etc.)
  • Vérifiez que les IDs référencés existent

Non trouvé (404)

Se produit lorsque la ressource demandée n’existe pas :
Comment résoudre :
  • Vérifiez que l’ID de la ressource est correct
  • Assurez-vous que la ressource n’a pas été supprimée
  • Vérifiez l’orthographe du slug si utilisé

Non autorisé (401)

Se produit lorsque l’authentification échoue :
Comment résoudre :
  • Vérifiez que l’en-tête Authorization est présent
  • Assurez-vous que la clé API est valide et non révoquée
  • Vérifiez le format : Bearer VOTRE_CLE_API

Limite de débit atteinte (429)

Se produit lorsque vous dépassez la limite de requêtes :
Comment résoudre :
  • Attendez le temps indiqué dans l’en-tête Retry-After
  • Implémentez un backoff exponentiel
  • Réduisez la fréquence de vos requêtes

Erreur serveur (500)

Se produit en cas de problème côté serveur :
Comment résoudre :
  • Réessayez la requête après quelques secondes
  • Vérifiez le statut du service
  • Contactez le support si le problème persiste

Gestion des erreurs

Exemple en JavaScript

Exemple en PHP

Bonnes pratiques

Ne présumez jamais qu’une requête a réussi. Vérifiez toujours le code de statut HTTP.
Conservez un journal des erreurs API pour le débogage et la surveillance.
Traduisez les erreurs techniques en messages compréhensibles pour vos utilisateurs.
Pour les erreurs transitoires (500, 429), implémentez une logique de réessai avec backoff.