# Nouvelles tentatives et échecs

> Comment Emailit réessaie les requêtes de webhook en échec, quand il vous envoie un e-mail et désactive un endpoint, et comment inspecter et renvoyer les requêtes en échec.

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 :

| Tentative | Délai après la tentative précédente | Temps écoulé depuis la première tentative |
| --- | --- | --- |
| 1 | Envoyée quelques secondes après l’événement | 0 |
| 2 | 5 minutes | 5 minutes |
| 3 | 30 minutes | 35 minutes |
| 4 | 2 heures | 2 heures 35 minutes |
| 5 | 5 heures | 7 heures 35 minutes |
| 6 | 12 heures | 19 heures 35 minutes |
| 7 | 12 heures | 1 jour 7 heures |
| 8 | 12 heures | 1 jour 19 heures |
| 9 | 12 heures | 2 jours 7 heures |
| 10 | 12 heures | 2 jours 19 heures |
| 11 | 12 heures | 3 jours 7 heures |

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](#resend-failed-requests) 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 :

| Quand | E-mail |
| --- | --- |
| Une requête échoue pour la troisième fois (environ 35 minutes après le premier échec) | Le webhook est en échec. Envoyé une fois par incident. Vous n’en recevez un autre qu’après une livraison réussie suivie de nouveaux échecs, ou au bout de 4 jours. |
| Le webhook est désactivé automatiquement | Le webhook a été désactivé, avec le dernier code de statut. |

## 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](/fr/docs/logs/events/).
- 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](/fr/docs/api-reference/webhooks/update/) 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 :

| Colonne | Description |
| --- | --- |
| **Event type** | L’événement contenu dans la requête. |
| **Event ID** | L’ID `evt_`, la même valeur que celle que votre endpoint reçoit dans `event_id`. |
| **Created** | Date de mise en file d’attente de la requête. |
| **Attempts** | Nombre de tentatives de livraison en échec jusqu’à présent. |
| **Status** | **Pending** (pas encore tentée), **Attempting** (en échec au moins une fois, fera l’objet d’une nouvelle tentative), **Delivered** ou **Failed** (nouvelles tentatives épuisées). |

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](/fr/docs/api-reference/webhooks/retry-request/), `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](/fr/docs/api-reference/webhooks/retry-failed/) :

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

```json
{ "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](/fr/docs/api-reference/webhooks/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](/fr/docs/logs/events/#reconcile-missed-webhook-events) 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](/fr/docs/webhooks/webhook-requests/#duplicates).

## 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**.

| | Pay as you go | Pro | Business | Custom |
| --- | --- | --- | --- | --- |
| Conservation des logs de requêtes | 7 jours | 30 jours | 30 jours | Flexible |

## Voir aussi

  - [Requêtes de webhook](/fr/docs/webhooks/webhook-requests/)
  - [Événements](/fr/docs/logs/events/)

---
Source: https://emailit.com/fr/docs/webhooks/retries-and-failures/