What a Webhook Payload Tester Shows
A webhook payload tester gives a sender a temporary HTTP endpoint and records the complete request delivered to it. That request includes more than JSON: the method, content type, provider headers, query parameters, raw body, source address, and arrival time all help explain what happened.
The JSON body describes the event, while headers usually carry routing and security context. Event type, delivery ID, API version, signature, and user agent headers can be essential even when the body looks correct.
Use the captured request as evidence. Compare every required field with the provider contract before writing application logic, and keep the sample synthetic so no customer data or secrets enter a public debugging endpoint.
- Confirm the method and Content-Type before parsing
- Record event type, delivery ID, and version headers
- Inspect the raw body as well as formatted JSON
- Use test objects and redacted credentials only
Send a Safe Webhook Payload Example
Start with a small event that has a stable identifier, an explicit type, a timestamp, and one nested object. This makes field names and data types easy to inspect without copying a real provider payload.
Send the example as application/json and add a synthetic event header. After delivery, check that the request body still contains a number as a number, a boolean as a boolean, and the timestamp in the expected format.
A successful request is only the baseline. Repeat the test with a missing field, an unknown field, null, an empty object, and an invalid type to define how strict the future receiver should be.
{
"id": "evt_test_123",
"type": "order.created",
"created_at": "2026-08-02T12:00:00Z",
"data": {
"order_id": "ord_test_456",
"amount": 4900,
"currency": "USD",
"paid": true
}
}Validate JSON Shape and Meaning
Valid JSON is not automatically a valid webhook payload. A body can parse correctly while omitting the event ID, using the wrong event type, or changing an amount from a number to a string.
Write a schema for the fields your receiver actually consumes. Mark required and optional values, define accepted types and formats, and decide what should happen when a provider adds an unknown field in a later version.
Prefer tolerant reading and strict business validation. Ignoring a harmless new field can preserve compatibility, while rejecting an unsupported event type or malformed required value protects downstream processing.
- Separate JSON syntax validation from business validation
- Require a stable ID before any side effect
- Route only known event types
- Treat money, timestamps, and identifiers as explicit contracts
- Keep unknown-field behavior documented and tested
Preserve Raw Bytes for Signature Verification
Many providers sign the exact request bytes. Parsing JSON and serializing it again can change whitespace, escaping, or key order, so the reconstructed text may not match the signature even though the data looks identical.
Capture the raw request body before framework middleware transforms it. Verify the provider signature against those bytes, then parse and validate the JSON only after authenticity has been established.
A public inspector is useful for learning the payload shape, but production signature verification belongs in your own trusted receiver. Keep signing secrets in a secret manager and never send them inside a test event.
Turn the Capture Into Repeatable Tests
After reviewing the delivery, remove endpoint URLs, secrets, personal data, and provider credentials before saving it as a fixture. Keep only the fields needed to reproduce parser and routing behavior.
Create fixtures for the happy path, missing required values, invalid types, unknown event types, duplicate IDs, invalid signatures, and oversized bodies. These cases reveal more than a single copied success payload.
Run the same fixtures in unit tests and staging. When a provider announces a new API version, capture a fresh synthetic event, compare it with the old fixture, and update the contract deliberately.
- Redact before committing any captured request
- Keep raw-body fixtures for signature tests
- Test duplicates and unsupported event types
- Version fixtures alongside parser changes
Common questions
Frequently asked questions
- What is a webhook payload?
- A webhook payload is the data a provider sends to a receiver when an event occurs. It is commonly a JSON request body accompanied by headers that identify the event, delivery, content type, signature, and provider.
- How do I test a webhook payload online?
- Create a temporary endpoint, send a synthetic event to its URL, and inspect the captured method, headers, query values, and raw body. Compare the result with the provider documentation before implementing the production parser.
- What should a webhook payload contain?
- Useful payloads usually include an event type, stable event or delivery ID, creation time, object data, and a schema or API version. Authentication and signature values normally belong in headers rather than the JSON body.
- Can a webhook payload tester verify signatures?
- A tester can show the raw body and signature header, but secret-based verification should run in code you control. Never paste a production signing secret into a public tester or include it in the payload.
Primary sources
Official references
Try it with a real request
Turn the guide into a test.
Open a temporary endpoint, send your payload, and inspect exactly what arrived.
Open the tester