What is a webhook consumer?

A webhook consumer is the receiving side of a webhook integration: the system that exposes an endpoint, accepts the provider's HTTP POSTs, and turns them into action. The Standard Webhooks specification uses the same term for the role its receiving-side recommendations address. If your service reacts to Stripe payments or GitHub pushes, your service is the consumer.

Sending webhooks?

Svix is the enterprise-ready webhook sending service. It handles signing, retries, and delivery observability, so you can ship a reliable webhook platform in minutes instead of months. Start sending webhooks with Svix.

What the consumer owns

The consumer's obligations are fewer than the provider's but unforgiving, because each one guards against a specific failure.

• Verification. Checking the signature on every request over the raw body, and rejecting anything outside the timestamp tolerance. Skipping this leaves the endpoint acting on whatever anyone POSTs to it.
• Fast acknowledgment. Returning 2xx within the provider's timeout, which in practice means queueing the event and processing asynchronously rather than doing real work in the request handler.
• Deduplication. Tracking message IDs and dropping repeats, since at-least-once delivery makes duplicates a certainty over time.
• Order tolerance. Not assuming events arrive in creation order, and comparing payload timestamps or versions where sequence matters.

The response code is the consumer's half of the delivery contract: 2xx stops retries, anything else invites them. Returning errors for messages the consumer will never accept, or 2xx for messages it silently failed to durably store, both corrupt the provider's picture of what was delivered.

Consumer versus provider

The provider owns whether a message arrives; the consumer owns what happens next. The roles are complementary rather than symmetrical: the provider's machinery (persistence, retries, signing) exists to make the consumer's job possible, and the consumer's discipline (verification, deduplication) exists to make the provider's guarantees safe to rely on. Most integrations put the same company in both roles somewhere, sending its own webhooks while consuming others'.

Consuming well with less code

Most of the consumer checklist is generic, which is why it keeps getting rebuilt badly. Provider-published verification libraries handle signatures and timestamps; for a consumer wiring up many providers at once, Svix Ingest takes the receiving side as a service, terminating deliveries, verifying, and forwarding clean events. The hands-on patterns, with code, live in the receiving best practices and the consuming webhooks lessons in Webhooks University.

Frequently asked questions

What must a webhook consumer do on every request?

Verify the signature against the raw body, check the timestamp is within tolerance, deduplicate on the message ID, and return a 2xx quickly, deferring real processing to a queue or background worker. Each step guards a distinct failure: forgery, replay, duplicates, and timeouts.

Should a webhook consumer return errors for bad events?

Return 4xx for requests that fail verification, since retrying them can never help. Return 2xx once a valid event is durably accepted, even if business processing happens later or eventually fails; the provider's retry exists for delivery problems, not for the consumer's internal ones.

Is a webhook consumer the same as a webhook receiver?

Yes, the terms are interchangeable. "Consumer" is the term the Standard Webhooks specification and most event-driven-architecture writing use; "receiver" appears more in provider documentation. Both mean the system the webhooks are delivered to.