Webhooks

La vue Webhooks comporte trois onglets : Événements, ce que votre compte a produit, Livraisons, les envois faits à partir de ces événements, et Points de terminaison, les adresses qui les ont reçus. Les événements disposent de leur propre page. Celle-ci traite des deux autres onglets.

Livraisons

Dernière heure

Method	Endpoint	Status	Duration	Tentative
POST	/webhooks/wajub	500	10021 ms	1
POST	/webhooks/wajub	500	240 ms	2
POST	/webhooks/wajub	200	142 ms	3

Livraisons

Une ligne correspond à une tentative, pas à un événement. Une livraison relancée trois fois produit trois lignes qui partagent le même identifiant de livraison.

Filtres : recherche dans l'événement, statut, endpoint et plage de dates en journées entières. Cinquante résultats par page.

Le panneau de détail contient le payload envoyé et le corps renvoyé par votre endpoint. Vous pouvez ainsi découvrir que votre erreur 500 contient une stack trace lisible directement ici.

Relancer des livraisons

Deux méthodes sont proposées, sur tous les plans, sans quota mensuel.

Relancer les livraisons échouées sélectionne uniquement les livraisons dont le statut est failed, dans la période choisie, qui couvre par défaut les dernières 24 heures. Filtrez la liste sur failed pour voir le bouton : avec des lignes cochées, il relance celles-ci ; sans aucune, il demande la période.

Une livraison dont l'endpoint a accepté l'événement depuis n'est pas renvoyée : une relance isolée le dit, et un lot l'ignore. Un événement qui a échoué plusieurs fois ne part qu'une fois.

Un même événement repart vers le même endpoint au plus une fois toutes les 5 minutes, que vous le renvoyiez d'ici, depuis la page de l'événement ou avec POST /events/{id}/resend. Dans ce délai, Renvoyer indique combien de minutes il reste. Relancer les livraisons échouées ignore ces livraisons et les compte dans son message ou, quand toutes celles qu'il trouve sont dans ce délai, indique quand les relancer.

Endpoints

La création d'un endpoint exige une URL et une liste de types d'événement.

Les adresses privées et internes sont volontairement refusées. Un endpoint qui pointe vers localhost ou vers une plage privée permettrait aux webhooks d'atteindre des réseaux privés. Pour le développement local, utilisez wajub listen.

Le secret

Chaque endpoint possède son propre secret de signature, affiché une seule fois lors de sa création. Ensuite, Afficher l'affiche à nouveau après la saisie d'un code de vérification de sécurité. Cette action est enregistrée.

Pour le renouveler, utilisez Renouveler à côté du secret sur la page de l'endpoint, derrière la même vérification de sécurité, ou POST /webhooks/{id}/rotate-secret depuis l'API. Le nouveau secret remplace l'ancien immédiatement et n'est affiché qu'une fois. Chaque tentative envoyée ensuite est signée avec lui, y compris les nouvelles tentatives d'événements envoyés avant le renouvellement : tant que votre gestionnaire ne le connaît pas, il les rejette. Faites-lui accepter deux secrets avant de renouveler, ajoutez le nouveau dès qu'il s'affiche, puis retirez l'ancien. Une livraison refusée entre-temps est retentée, signée avec le nouveau secret. La carte « Secret de signature de plus de 6 mois » de la vue d'ensemble compte depuis le dernier renouvellement.

Passer un endpoint en live

Les endpoints de sandbox et de live sont distincts. Pour recevoir les événements live, basculez le Dashboard sur Production et créez de nouveau l'endpoint avec la même URL et la même liste d'événements. Il reçoit un nouveau secret.

La page d'un endpoint de sandbox porte un bouton Passer en production qui fait cette copie en une seule action : il crée l'endpoint live avec la même URL et les mêmes événements, bascule le Dashboard sur Production et affiche une seule fois le nouveau secret live. Il refuse lorsqu'un endpoint live porte déjà cette URL, ou lorsque l'URL n'est pas en https://.

Envoyer un test : une vraie livraison, avec des données de test

Envoyer un test envoie à l'endpoint une livraison construite clé pour clé comme une vraie, signée avec le véritable secret de l'endpoint. Il prouve que l'URL est accessible, que votre vérification de signature réussit et que votre handler accepte l'enveloppe. Seul son contenu est fictif : l'événement est webhook.test et data est un exemple, il n'exerce donc pas le code qui traite un vrai type d'événement.

Le contenu qu'envoie le bouton Envoyer un test

{

"id": "evt_test_kZ3qP8mWvL2xR7tB5nY4hC6d",

"event": "webhook.test",

"data": {

"id": "test_123",

"message": "This is a test webhook from Wajub."

},

"livemode": false,

"pending_webhooks": 1,

"api_version": "2026-10-11",

"request": {

"id": null,

"idempotency_key": null

},

"created": "2026-01-15T10:30:00+00:00"

}

Il porte l'en-tête X-Wajub-Delivery-Id comme toute livraison, livemode suit l'environnement dans lequel se trouve le Dashboard, et la tentative est enregistrée dans les livraisons de l'endpoint avec le statut success ou failed, selon votre réponse. Il n'est pas relancé, et ce n'est pas un événement : GET /events ne le liste pas.