Skip to main content
Back to Dev generators

Dev

Fake Webhook Event Generator

Waiting for a real payment or subscription cancellation just to test your handler is impractical. This generator produces valid JSON payloads for five event types — payment.completed, user.signup, order.shipped, subscription.cancelled, and invoice.paid — with randomized but plausible fields on every run. The `eventType` input determines the data shape: payment.completed includes amount, currency, and status 'succeeded'; user.signup includes plan (free, pro, enterprise); order.shipped includes carrier and tracking number; subscription.cancelled includes cancellation reason; invoice.paid includes amount_due and paid_at. Every payload carries top-level id (evt_ prefix), type, created_at, and livemode: false. The `count` input generates 1 to 10 at once. Paste into curl, Postman, or Jest fixture files to test handler logic with no upstream dependency.

Read the complete guide — 4 min read

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. Select the event type you want to simulate from the Event Type dropdown (e.g., payment.completed, order.created).
  2. Set the Number of Events field to how many distinct payloads you need in this batch.
  3. Click Generate to produce the JSON payloads, each with unique randomized field values.
  4. Copy individual payloads or the full batch and paste into your webhook endpoint, test fixture file, or Postman request body.

Use Cases

  • Sending a payment.completed payload to a local Express webhook endpoint via curl before going live
  • Seeding Jest fixture files with 10 subscription.cancelled events to test idempotency and deduplication logic
  • Populating a Mockoon or WireMock server with order.shipped events for parallel frontend integration work
  • Generating invoice.paid payloads to validate HMAC signature verification inside a Pytest test suite
  • Demoing a webhook handler in a technical interview without needing a live Stripe sandbox account

Tips

  • Generate at least 5 events of the same type to catch bugs that only appear when IDs or timestamps vary between calls.
  • For idempotency testing, generate two batches and check that duplicate event IDs in your handler don't cause double-processing.
  • Combine payment.completed and payment.failed payloads in the same test run to validate that your error-handling branch is also covered.
  • When writing API docs, generate a single event, pretty-print it, and use it verbatim as your example payload — it's more credible than a hand-written stub.
  • If your consumer validates required fields strictly, inspect the generated payload first to confirm all fields your schema expects are present before writing assertions against them.

FAQ

how do I test a webhook handler locally without a real event firing

Generate your payload, copy the JSON, then send it with curl: curl -X POST http://localhost:3000/webhook -H 'Content-Type: application/json' -d '<pasted JSON>'. You can also paste it into Postman's body panel. If your handler requires a public HTTPS URL, expose a local tunnel with ngrok — but for parsing and routing logic, a direct curl call is sufficient.

are fake webhook payloads safe to commit to a public repo or use in a demo

Yes. Every name, email, transaction ID, and amount is randomly generated with no link to any real person or account. You can safely include generated payloads in public repos, Postman collections, documentation screenshots, or staging environments without GDPR or PCI concerns.

what is the difference between this tool and a service like webhook.site or a stripe sandbox

Webhook.site captures live traffic, so a real upstream event must fire before you see a payload. Stripe's sandbox requires account setup and live API keys. This generator produces structured, realistic payloads instantly with no upstream dependency — ideal for unit tests, offline development, and simulating specific event types that are expensive or time-consuming to trigger in a real environment.

what fields does the generator include in a payment.completed event

A payment.completed payload includes a top-level id (evt_ prefix), type, created_at, api_version, and livemode: false. The nested data.object contains id (pay_ prefix), object type, amount, currency (USD/EUR/GBP), customer_email, and status set to 'succeeded'. This covers the fields most payment handler logic reads.

You might also like

Popular tools from other categories that share themes with this one.

Try these next

More free tools from other corners of the catalog, picked by shared themes.