Nouvelles tentatives et échecs

Lorsque votre endpoint n’accepte pas une requête de webhook, Emailit conserve les événements et réessaie selon un calendrier qui s’étend sur un peu plus de trois jours. Cette page présente ce calendrier, explique les e-mails qu’Emailit envoie et quand il désactive un endpoint, et montre comment inspecter et renvoyer les requêtes en échec.

Ce qui est considéré comme un échec

Une requête échoue lorsque votre endpoint :

• Renvoie un statut en dehors de la plage 200–299, y compris les redirections (3xx).
• Ne répond pas dans les 30 secondes.
• Est injoignable : erreurs DNS, connexions refusées, erreurs TLS, ou URL qui se résout en adresse IP privée.

Un échec s’applique à tout le lot : tous les événements de la requête font ensemble l’objet d’une nouvelle tentative.

Calendrier des nouvelles tentatives

Après chaque tentative en échec, Emailit attend avant de réessayer :

Si la tentative 11 échoue, la requête est marquée Failed et ne fait plus l’objet de nouvelles tentatives automatiques. Vous pouvez encore la renvoyer pendant 7 jours.

Chaque tentative est signée de nouveau avec un nouvel horodatage. Les événements qui arrivent pendant que des requêtes antérieures attendent une nouvelle tentative sont envoyés dans leurs propres lots : un événement problématique ne bloque pas les plus récents.

E-mails de notification

Emailit envoie un e-mail au propriétaire de l’espace de travail à deux moments :

Désactivation automatique

Si un webhook n’a connu aucune livraison réussie pendant 3 jours depuis sa plus ancienne requête en échec, Emailit le désactive à la tentative en échec suivante. En pratique, cela se produit vers la 11ᵉ tentative de la première requête en échec, ou plus tôt si de nouveaux événements continuent d’échouer.

Tant qu’un webhook est désactivé :

• Les nouveaux événements ne sont pas mis en file d’attente pour lui. Ils sont tout de même enregistrés dans le flux d’événements.
• Les requêtes qui attendaient une nouvelle tentative restent en attente et reprennent lorsque vous le réactivez.
• La page du webhook affiche le statut Disabled.

Pour le réactiver, sélectionnez Enable webhook dans le menu d’actions du webhook, ou appelez Mettre à jour un webhook avec {"enabled": true}. Retry failed et la relance d’une requête individuelle réactivent aussi le webhook.

L’onglet Requests

Ouvrez un webhook dans Email API›Webhooks pour afficher son onglet Requests, du plus récent au plus ancien :

Filtrez par Status code, Event ou Created. Les événements de test envoyés avec Send test n’apparaissent pas ici.

Pour une requête Failed, sélectionnez View pour ouvrir Failure reason : le code de statut renvoyé par votre endpoint (0 en l’absence de réponse HTTP), la date de création et la date d’échec de la requête, et les 2 000 premiers caractères du corps de la réponse.

Renvoyer les requêtes en échec

Vous pouvez renvoyer les requêtes marquées Failed dont le dernier échec date de moins de 7 jours. Les requêtes renvoyées repassent à Pending et démarrent un nouveau cycle de tentatives à partir de la tentative 1. La livraison n’est pas instantanée : le prochain cycle de livraison les prend en charge en quelques secondes.

Relancer une requête

Dans l’onglet Requests, sélectionnez Retry sur une ligne en échec. Le bouton n’apparaît que sur les requêtes en échec des 7 derniers jours.

L’endpoint de l’API est Relancer une requête, POST /v2/webhooks/{id}/requests/{request_id}/retry, qui renvoie {"retried": 1, "id": "whr_…"}. Il n’accepte que les requêtes marquées Failed et renvoie 400 pour les autres. Aucun endpoint public ne liste les ID de requête (whr_…) : pour l’automatisation via l’API, utilisez plutôt Retry failed.

Relancer les requêtes en échec

Ouvrez le menu d’actions du webhook et sélectionnez Retry failed. Toutes les requêtes en échec des 7 derniers jours sont remises en file d’attente, et le tableau de bord affiche « Queued 3 failed request(s) for retry » avec le nombre réel, ou « No failed requests in the last 7 days ».

Via l’API, appelez Relancer les requêtes en échec :

curl -X POST https://api.emailit.com/v2/webhooks/wh_2xGk8Hd3RvN6qT1mWsB9cL4pZ7e/retry-failed \
  -H "Authorization: Bearer $EMAILIT_API_KEY"

{ "retried": 42 }

Se remettre d’une panne

1. Corrigez l’endpoint. Utilisez View sur une requête en échec pour voir ce que votre endpoint a renvoyé.

2. Vérifiez qu’il fonctionne. Utilisez Send test dans le menu d’actions, ou Envoyer un événement de test via l’API, et vérifiez que vous obtenez un 2xx.

3. Réactivez le webhook si Emailit l’a désactivé.

4. Renvoyez les échecs. Sélectionnez Retry failed pour remettre en file d’attente toutes les requêtes en échec des 7 derniers jours. Les requêtes encore marquées Attempting sont réessayées selon leur propre calendrier.

5. Comblez les manques. Les événements survenus pendant que le webhook était désactivé n’ont jamais été mis en file d’attente, et les échecs de plus de 7 jours ne peuvent pas être renvoyés. Lisez-les avec l’API des événements pour la période concernée et traitez ceux qui vous manquent.

Comme les nouvelles tentatives renvoient des lots entiers, rendez votre gestionnaire idempotent : enregistrez chaque event_id et ignorez ceux que vous avez déjà traités. Consultez Requêtes de webhook.

Conservation

Les requêtes de webhook suivent la durée de conservation des Logs : les lignes les plus anciennes disparaissent progressivement de l’onglet Requests.

Voir aussi