From capture to confidence
in four simple steps
A streamlined workflow that takes you from receiving your first webhook to monitoring production integrations with confidence.
Create your endpoint
Spin up a Debug Endpoint in seconds. Get a unique HTTPS URL that captures every incoming request with full HTTP details.
Inspect every detail
View requests in real-time. Search and filter by source, status, or content. Validate signatures and beautify JSON.
Replay & forward
Replay any request to production, staging, or your local machine via CLI tunnel. Compare responses and attach notes.
Monitor & alert
Set up Monitors to detect when webhooks stop arriving. Get notified via Email or Slack before issues impact your users.
Start with a real webhook payload
Hooklistener gives you a public endpoint for capturing webhooks, a request history for inspecting what arrived, and replay tools for testing your handler again. Use it when you need to understand a provider's payload before writing code, investigate a failed delivery, or check a fix against the request that exposed the bug.
Create an endpoint, copy its URL, and use it as the webhook destination in your provider's settings. Trigger a test event and open the captured request. The endpoint setup guide walks through quick creation, custom responses, and your first delivery. Start with test data so you can explore the payload without involving real customer activity.
Use request history to locate the failure
A missing update in your application does not tell you whether the provider sent an event, the request reached its destination, or your handler processed it correctly. Request history gives you a place to start: look for the expected delivery, then inspect its HTTP method, headers, and body. Check the event type and the identifiers your application uses to find the relevant record.
For example, a payment handler might expect a field at the wrong level of a JSON object. Comparing the captured payload with your code can reveal that mismatch. If no request appears, check the provider's configured URL and event subscriptions first. History availability depends on your plan; consult pricing and retention details when choosing how long you need to keep debugging evidence.
Replay a captured request after changing your code
Once you have a failing example, fix the handler and replay the captured request to a test destination. This lets you exercise the same payload again without repeating the original action in the provider. Check both the HTTP response and the resulting application state: a successful response alone does not prove that an order, payment, or repository update was handled correctly.
Replays are new delivery attempts. Use a development or staging environment and make your handler idempotent so repeated event IDs do not create duplicate effects. Signed webhooks may need fresh signatures or timestamps under the provider's verification rules. See the capture, inspection, and replay features for the tools available around this workflow.
Test Stripe or GitHub webhooks on localhost
When your handler runs on your laptop, the provider needs a public URL to reach it. Hooklistener's CLI tunnel forwards incoming requests to your local server. Keep the server and tunnel running, configure the public URL with the correct webhook path, and inspect your application logs as events arrive. Follow the CLI tunnel guide for commands and routing options.
Use the Stripe webhook guide to test payment events, or the GitHub repository webhook guide to work with repository events. In either case, verify the provider's delivery result alongside your handler's behavior before moving the integration to production.