Webhook test
Envoyez une requête à l'URL ci-dessous et regardez-la arriver : méthode, chemin, query, en-têtes, corps, type de contenu et IP source, en direct.
Créer un endpoint de test
Nous vous donnons une URL. Envoyez-lui n'importe quelle requête HTTP et la requête apparaît ici, en-têtes et corps compris. Rien n'est créé tant que vous n'appuyez pas sur le bouton.
Ce qu'un webhook receiver vous montre
Un webhook receiver répond à une requête HTTP et en garde la trace. Celui-ci affiche la méthode et le chemin, chaque en-tête tel qu'il a été envoyé, la query, le corps, le type de contenu et l'adresse d'où la requête est partie, pour comparer ce que votre code voulait envoyer avec ce qui est réellement sorti.
Un navigateur consigne les mêmes informations pour chaque requête d'une page, dans un fichier HAR plutôt que ligne par ligne. Si c'est plutôt cela qu'il vous faut, commencez par comment enregistrer un fichier HAR, le lire et le partager sans risque.
Envoyer un webhook test depuis votre propre code
Pointez n'importe quel client vers l'URL ci-dessus : curl, une bibliothèque HTTP, le bouton de test d'un prestataire de paiement ou un job de votre build. Toutes les méthodes sont acceptées, le chemin qui suit l'identifiant de l'endpoint est enregistré tel quel, et les lignes apparaissent ici sans recharger la page.
Les webhooks font aussi sortir le travail de Session Replay, pas seulement entrer dans un endpoint de test. Un rapport de bug terminé part là où votre équipe travaille déjà : un rapport devient un ticket Jira ou une carte que votre canal peut trier.
Questions
Vous venez de voir tout ce que transportait une requête HTTP
C'est à cela qu'un rapport de bug devrait ressembler. Session Replay capture l'écran, la sortie console, le journal réseau et les détails du navigateur depuis la page où le bug s'est produit, pour que personne n'ait à le reproduire d'abord.