Webhook Tester

Un testeur de webhooks est une adresse publique temporaire qui enregistre chaque requête HTTP qui lui est envoyée, afin que vous voyiez exactement ce qu’un expéditeur de webhooks a réellement livré. Créez un hook ci-dessous et vous obtenez une URL unique qui vit 30 minutes : pointez Stripe, GitHub, un prestataire de paiement, un service de supervision ou votre propre code vers elle, déclenchez l’événement, et chaque livraison arrive ici — méthode, chemin et requête, en-têtes, corps et adresse source — pour que vous l’inspectiez avant de brancher le vrai gestionnaire.

Dernière mise à jour:

Ce que ce service stocke — et ce qu’il ne fait jamais

Créer un hook ne stocke, sur le serveur de vérification SysOSX, que l’identifiant du hook, ses heures de création et d’expiration et l’adresse qui l’a créé. Chaque requête capturée stocke l’heure d’arrivée, la méthode, le chemin avec sa chaîne de requête, les en-têtes exactement comme envoyés, le corps jusqu’à 256 Ko (au-delà, il est tronqué et signalé) et l’adresse de l’expéditeur. Un hook conserve au maximum 50 requêtes ; les livraisons suivantes sont refusées jusqu’à son expiration. Tout est supprimé 30 minutes après la création du hook, ou immédiatement lorsque vous appuyez sur le bouton de suppression. Le récepteur ne fait que recevoir : il ne va jamais chercher, suivre ou rejouer quoi que ce soit — une requête capturée ne déclenche aucun appel sortant. Pour l’outil de débogage voisin, voyez le traceur de chaîne de statuts HTTP, et pour le flux complet lisez déboguer les webhooks sans la plomberie.

Pourquoi déboguer les webhooks est pénible sans récepteur

Un webhook, c’est le serveur de quelqu’un d’autre qui appelle le vôtre, selon son calendrier, en réponse à un événement que vous ne contrôlez pas — un paiement qui aboutit, un push qui arrive, une alerte qui se déclenche. Cette forme est précisément ce qui rend les webhooks pénibles à déboguer. L’expéditeur ne peut pas atteindre votre portable, donc le développement local exige un tunnel ou une machine publique de préproduction avant de voir une seule livraison réelle ; l’événement peut être difficile à déclencher deux fois, donc l’unique livraison que vous obtenez a intérêt à être capturée entièrement ; et quand quelque chose échoue, le tableau de bord de l’expéditeur ne montre généralement que le code de statut que votre point de terminaison a renvoyé, pas ce qu’il a réellement envoyé. L’en-tête de signature était-il présent ? Le corps avait-il la forme JSON promise par la documentation, ou était-il encodé en formulaire ? La nouvelle tentative a-t-elle envoyé le même identifiant d’événement ? Aucune de ces questions ne peut trouver de réponse dans les seuls journaux de votre gestionnaire si celui-ci a rejeté la requête avant de la journaliser — ce qui est exactement ce qui se produit avec les bogues de signature et d’analyse qui dominent le débogage des webhooks.

Un récepteur temporaire retire la plomberie de cette boucle. Au lieu de déployer un gestionnaire à moitié écrit juste pour voir ce qui arrive, vous créez une adresse qui accepte tout, l’enregistre fidèlement et vous le montre : les en-têtes dans l’ordre et la casse où ils sont arrivés, le corps brut avant qu’un analyseur ait pu le rejeter, la chaîne de requête dans laquelle les expéditeurs cachent parfois des paramètres, et la méthode exacte — car certains prestataires livrent en POST, d’autres en PUT, et quelques-uns vérifient l’état en GET. Avec une vraie livraison capturée à l’écran, vous pouvez écrire votre gestionnaire contre la vérité plutôt que contre la documentation, construire un fixture pour vos tests à partir de la charge réelle et comparer côte à côte une nouvelle tentative échouée avec l’original. Puis vous supprimez le hook, pointez le prestataire vers votre vrai point de terminaison et déclenchez l’événement une fois de plus pour regarder votre propre gestionnaire y répondre. Trente minutes, c’est délibérément court : assez long pour une session de débogage, assez court pour qu’une adresse de test oubliée et pleine de charges capturées ne traîne pas sur Internet.

Questions fréquentes

Combien de temps un hook vit-il, et combien peut-il capturer ?

Un hook vit 30 minutes à partir de sa création ; ensuite, le hook et tout ce qu’il a capturé sont supprimés automatiquement. Il conserve jusqu’à 50 requêtes ; les livraisons au-delà sont refusées avec une réponse 429 jusqu’à l’expiration du hook. Chaque corps est stocké jusqu’à 256 Ko — un corps plus long est tronqué et la capture est signalée comme tronquée, pour que vous sachiez que vous ne voyez pas tout.

Qui peut voir ce que mon hook capture ?

Quiconque possède l’URL du hook. L’identifiant dans l’URL est le seul justificatif : il autorise l’envoi de requêtes et la lecture des captures, sans compte ni mot de passe par-dessus. C’est ce qui rend l’outil instantané à utiliser, et c’est pourquoi vous devez traiter l’URL comme un mot de passe — ne la publiez pas et ne pointez jamais de trafic de production contenant des secrets ou des données personnelles vers un visualiseur partagé comme celui-ci.

Le récepteur répond-il à l’expéditeur, suit-il des liens ou rejoue-t-il des requêtes ?

Non. Le récepteur répond à chaque livraison acceptée par un petit accusé JSON 200 indiquant qu’elle est arrivée, et ne fait rien d’autre d’elle : il ne va jamais chercher les URL trouvées dans une charge, ne suit jamais les redirections et n’offre ni rejeu ni transfert. Recevoir et inspecter, c’est tout le service, ce qui empêche une charge capturée de se transformer en trafic sortant.

Quels expéditeurs puis-je tester avec ceci ?

Tout ce qui peut envoyer une requête HTTP à une URL publique : Stripe, GitHub, Shopify, les prestataires de paiement et de formulaires, les services de supervision et de CI, un appareil IoT, ou votre propre code avec curl. Créez le hook, collez l’URL dans les réglages webhook du prestataire (ou dans votre script), déclenchez l’événement et regardez la livraison arriver ici en quelques secondes. Pensez à retirer l’URL de test chez le prestataire ensuite, ou à la pointer vers votre vrai gestionnaire.