Webhook Payload Generator: Test Handlers Without Live Events
Webhooks power real-time integrations — but testing them during development means waiting for real events or manually constructing JSON. Our Webhook Payload Generator produces realistic, randomly-seeded payloads for the most common webhook sources so you can test your handler logic immediately.
What Webhooks Are
A webhook is an HTTP POST request that a service sends to your URL when something happens. GitHub sends a push event when commits are pushed; Stripe sends payment_intent.succeeded when a charge clears; Slack sends message events when users post. Your handler receives the JSON body and acts on it — update a database, send a notification, trigger a pipeline.
Testing With Sample Payloads
Copy a payload and POST it with curl: curl -X POST http://localhost:3000/api/webhook -H 'Content-Type: application/json' -d '{...}'. For local development, use ngrok to expose your server so real services can reach it, then replay events from your provider's dashboard to compare with the generator output.
Signature Verification
In production always verify the webhook signature. GitHub signs with HMAC-SHA256 and sends it in the X-Hub-Signature-256 header. Stripe sends Stripe-Signature with a timestamp and v1 HMAC. Compute the HMAC of the raw request body using your webhook secret, then compare using a constant-time equality check to prevent timing attacks.
Idempotent Handlers
Webhook providers guarantee at-least-once delivery — your handler may receive the same event multiple times. Always make handlers idempotent: check if you have already processed the event ID before acting. Stripe, GitHub, and Slack all include a unique event/delivery ID you can store and deduplicate against.
Practical Examples
Testing a Stripe payment handler
Simulate a successful payment without a real transaction.
- 1.Select Stripe → payment_intent.succeeded
- 2.Copy the payload JSON
- 3.POST to your local handler: curl -X POST http://localhost:3000/api/stripe -H 'Content-Type: application/json' -d '
' - 4.Verify your handler updates the order status to 'paid'
Testing a GitHub CI trigger
Trigger your CI pipeline from a simulated push event.
- 1.Select GitHub → push
- 2.Click Regenerate to get a fresh commit SHA
- 3.POST to your CI webhook endpoint
- 4.Verify the pipeline starts with the correct branch/commit
Frequently Asked Questions
What is a webhook payload?
A webhook payload is the JSON body sent by a service (GitHub, Stripe, Slack, etc.) to your endpoint URL when a specific event occurs. For example, when a pull request is opened on GitHub, it POSTs a JSON object with the PR details to any registered webhook URL.
Why do I need sample webhook payloads?
During development you want to test your webhook handler logic without triggering real events — real Stripe payments, real GitHub pushes, etc. Sample payloads let you feed data directly into your handler via tools like curl, Postman, or automated tests.
How do I use these payloads to test my handler?
Copy the generated JSON, then POST it to your local endpoint using curl: `curl -X POST http://localhost:3000/api/webhook -H 'Content-Type: application/json' -d '
Are the IDs and timestamps real?
No — IDs are randomly generated hex strings and timestamps are the current time. They follow the real format (e.g. Stripe uses pi_xxx for PaymentIntents, GitHub uses 40-char hex for commit SHAs) but are not valid credentials or real identifiers.
Why does Regenerate produce a different payload?
Each provider definition calls a function that generates random IDs and uses the current timestamp. Clicking Regenerate re-calls that function, so you get fresh IDs — useful for simulating multiple distinct events in sequence.
How do I verify a webhook signature in my handler?
Most services sign their payloads. GitHub uses HMAC-SHA256 with a secret and sends it in X-Hub-Signature-256. Stripe sends the signature in Stripe-Signature. You compute the HMAC of the raw request body using your webhook secret and compare it to the header value.
What is the difference between event types for the same provider?
One provider (e.g. Stripe) sends different payload shapes for different events. A payment_intent.succeeded event has different fields than a customer.subscription.created event. Each has its own handler logic and the type field tells you which one arrived.
Can I add custom fields to the payload?
Yes — copy the JSON into any editor, add your custom fields, and POST the modified payload to your handler. The generator gives you a realistic starting point; you are free to modify it for edge-case testing (e.g. missing fields, null values).