A payload is the body of an HTTP request — the data the sender wants the receiver to act on. In webhooks, the payload is almost always JSON: a structured representation of the event (event type, ID, timestamp, the affected object).
A typical webhook payload includes:
- Event type — what happened (
payment_intent.succeeded) - Event ID — unique identifier for dedup
- Timestamp — when it happened
- Data — the affected resource (the customer, the amount, the order)
Provider conventions vary in details — Stripe nests data under data.object, GitHub uses top-level fields, Slack wraps everything in an event envelope — but the structure is similar across the industry.
How production systems process payloads
Beyond parsing, production webhook systems usually need to:
- Verify signatures on raw bytes before parsing (see HMAC)
- Persist the original payload for replay (see replay and dispatch snapshot)
- Transform the payload into the shape the consumer expects
- Filter on payload contents to route events to the right destination
For the broader primer: JSON payloads explained.
Related terms
- Webhook
An HTTP request one service sends to another to notify it that something happened.
Read - Dispatch snapshot
The transformed payload at the moment of dispatch, persisted so replays remain correct under config change.
Read - Replay
Re-running a retained event with the same input — typically after fixing a bug that caused the original to fail.
Read - Attempt
One HTTP request within a delivery's retry chain.
Read