Le rejeu webhook renvoie un callback HTTP précédemment capturé vers votre handler local sans redemander au provider de livrer l'événement. Au lieu de re-déclencher un paiement Stripe ou un push GitHub, vous rejouez la requête exacte — en-têtes, corps et tout.
Pourquoi le rejeu compte
Le débogage webhook suit souvent une boucle pénible : déclencher, inspecter, corriger, re-déclencher. Re-déclencher upstream est lent, bruyant et parfois impossible (événements uniques, ressources supprimées, rate limits).
Le rejeu compresse cette boucle : capturez une fois, corrigez, rejouez jusqu'à ce que le handler passe.
Comment fonctionne le rejeu webhook
- Un callback arrive sur votre URL tunnel et est forwardé localement.
- L'outil capture méthode, chemin, en-têtes et corps.
- Vous corrigez le handler d'après la requête capturée.
- Vous rejouez la requête en une action.
- Répétez jusqu'à la bonne réponse.
Cela requiert un tunnel localhost avec capture intégrée.
Cas d'usage
Développement handler : rejouez le même événement Stripe dix fois en affinant le parsing.
Idempotence : confirmez que les doublons de retry sont traités sans double facturation.
Signatures : isolez si l'échec vient de la vérification ou du parsing.
Régression : rejouez après refactors pour attraper les régressions avant deploy.
Rejeu vs re-déclenchement
- Rejeu : bugs handler, parsing, idempotence, signatures.
- Re-déclenchement : génération côté provider, registration webhook, intégration E2E.
Guides provider : Stripe, GitHub, Twilio. Guide général : déboguer les webhooks en local.
Commencez PortPreview gratuitement.
Bonnes pratiques de rejeu
Validez toujours les signatures lors du rejeu. Testez les livraisons dupliquées en rejouant le même événement plusieurs fois. Conservez l'historique des requêtes pendant les branches feature pour les checks de régression. Utilisez des credentials test-mode pour ne jamais affecter les données production.