Pour commencer
Erreurs et nouvelles tentatives
Analysez l’enveloppe d’erreur JSON standard et déterminez quand une nouvelle tentative est sûre.
Enveloppe d’erreur
Les échecs de l’API JSON utilisent un unique objet error de premier niveau, avec un message lisible, le status HTTP numérique et un code stable facultatif. Le contrat OpenAPI référence ce schéma pour les échecs attendus comme inattendus.
{
"error": {
"code": "invalid_request",
"message": "A verified From domain is required",
"status": 403
}
}Erreurs client
Corrigez les erreurs de saisie 400 avant de réessayer. Remplacez ou révoquez les identifiants invalides après une 401. Une 402 exige un droit d’accès payant, 403 signale une limite de politique ou d’autorisation, 404 correspond à une ressource introuvable dans le périmètre du tenant, 409 à un conflit d’état ou d’idempotence, 413 à un dépassement des limites de pièces jointes, et 422 couvre les erreurs de validation ou de suppression.
Décider d’une nouvelle tentative
Ne réessayez pas automatiquement les échecs d’authentification, de validation, de suppression ou de conflit. Une 423 signifie que l’identité From exacte est en pause : arrêtez ce flux, corrigez ses destinataires et ne réessayez qu’une fois ses indicateurs glissants revenus à la normale. Un appelant peut réessayer une réponse transitoire 429, 502 ou 503 avec un backoff exponentiel borné et du jitter. Conservez la même Idempotency-Key et un payload JSON identique lorsque vous réessayez un même envoi logique.
Contexte pour le support
Notez l’heure de la requête, la route, le statut HTTP, l’identifiant de ressource SendHQ et les champs d’erreur non secrets. N’incluez jamais de clé API, de cookie de session, de corps de message ni de liste de destinataires dans un signalement au support.