Aperçu
L’API Smartbills utilisé les codes de réponse HTTP conventionnels pour indiquer le succès ou l’échec d’une requête API. Les codes dans la plage2xx indiquent le succès, 4xx indiquent les erreurs du client, et 5xx indiquent les erreurs du serveur.
Codes de statut HTTP
Format de réponse d’erreur
Toutes les erreurs suivent une structure JSON cohérente :Champs d’erreur
Codes d’erreur
Erreurs d’authentification
Erreurs de permission
Erreurs de validation
Erreurs de ressource
Erreurs de limite de débit
Erreurs serveur
Gérer les erreurs avec le SDK
Les SDK Smartbills fournissent des classes d’erreur typées pour une gestion structurée des erreurs :Erreurs de validation
Les erreurs de validation incluent des informations détaillées sur les champs en échec :Logique de réessai
Implementez une logique de réessai avec un backoff exponentiel pour les erreurs transitoires :Débogage avec les ID de requête
Chaque réponse d’erreur inclut unrequestId. Incluez-le lorsque vous contactez le support :
- Le
requestIdde la réponse d’erreur - Le point d’accès et la méthode HTTP que vous avez appeles
- L’horodatage de l’erreur
- Une description de ce que vous attendiez
Bonnes pratiques
Toujours vérifier le statut de la réponse
Toujours vérifier le statut de la réponse
Ne supposez jamais qu’une requête à réussi. Vérifiez toujours le code de statut HTTP ou interceptez les exceptions du SDK.
Utiliser des gestionnaires d'erreurs par type
Utiliser des gestionnaires d'erreurs par type
Gérez les differents types d’erreurs avec les actions appropriees : rediriger vers la connexion pour 401, afficher les erreurs de champ pour les échecs de validation, réessayer pour 429/5xx.
Journaliser les erreurs avec contexte
Journaliser les erreurs avec contexte
Journalisez les erreurs avec suffisamment de contexte, y compris l’ID de requête, le point d’accès et les paramètres pertinents.
Afficher des messages conviviaux
Afficher des messages conviviaux
N’affichez pas les messages d’erreur bruts de l’API aux utilisateurs finaux. Mappez les codes d’erreur à des messages conviviaux dans votre application.
Implementer une logique de réessai
Implementer une logique de réessai
Implementez un backoff exponentiel pour les erreurs transitoires (429, 5xx). Ne retentez pas les erreurs du client (4xx autre que 429).
Ressources connexes
Limites de débit
Gérer la limitation de débit
Authentification
Corriger les erreurs d’authentification
Introduction à l'API
Aperçu de l’API
Webhooks
Configurer les webhooks