Architecture Patterns

Webhooks & Event Notifications

Term 61 of 68 in the ERPStack technical glossary

What is Webhooks & Event Notifications?

A webhook is an HTTP callback that allows one system to notify another system in real time when a specific event occurs — eliminating the need for polling APIs and enabling event-driven integrations between ERP modules and third-party services.

Webhooks & Event Notifications at a glance

Direction: Server-to-server push — 1 call when the fact occurs, instead of a poll every 60 seconds
Authenticity: HMAC-SHA256 signature over the raw body, verified in constant time before parsing
Delivery: At-least-once with exponential backoff; return 200 within seconds, process asynchronously
Replay defence: A signed timestamp plus a stored event id, so 1 captured request cannot be replayed later
Built with: Next.js 16 route handlers verifying HMAC-SHA256, queueing into PostgreSQL 18 through Drizzle ORM 0.45 or Redis, workers on Docker, deployed to Vercel or AWS with Sentry on failures and OpenTelemetry traces
Numbers that matter: Return 200 within seconds; 2 deliveries of 1 event must produce 1 effect; HMAC-SHA256 over the raw body; 1 stored event id per replay check; 3 handler steps — verify, persist, acknowledge
Compare with: Polling a REST API every 60 seconds, or consuming an Apache Kafka topic directly where you control both ends
Commonly paired with: Redis queues, Idempotency in API Design, Apache Kafka fan-out, Sentry alerting and SSO-protected admin tools
Status codes the sender reads: 200 or 202 acknowledges receipt; 400 means never retry; 401 and 403 mean fix credentials; 410 means unsubscribe; 429 means back off. RFC 9110 (June 2022) defines HTTP semantics; RFC 6585 (April 2012) added 429.
Signature basis: HMAC as specified in RFC 2104, February 1997, with a SHA-256 digest over the raw body, compared in constant time.
Who sends them: Salesforce, HubSpot, Microsoft Dynamics 365, Zoho Creator, monday.com and Odoo all emit them. An ERP consuming 6 vendors needs 1 verification path, not 6.
Retry ladder: A fixed ladder, not a tight loop: 1 minute, then 5, 30 and 60, giving up at 24 hours. Redis holds the schedule; a 410 unsubscribes on the 1st failure, not the 24th.

How Webhooks & Event Notifications works in production

Polling APIs (repeatedly checking 'has anything changed?') is wasteful and slow. Webhooks invert the relationship: the source system sends an HTTP POST to a registered URL when an event fires — e.g., Stripe sending a payment.succeeded event to your ERP's billing module. Webhooks require endpoint signature verification (HMAC-SHA256) to prevent spoofed events, idempotency key handling for retries, and dead-letter queues for failed deliveries.

The ERPStack approach to Webhooks & Event Notifications

We build hardened webhook endpoints in Next.js API routes with Svix or in-house HMAC signature verification, idempotency keys backed by PostgreSQL, and SQS dead-letter queues for zero-loss event delivery.

Related Resources

Frequently asked questions about Webhooks & Event Notifications

Why use Webhooks & Event Notifications instead of polling?

Latency and waste. Polling every 60 seconds means the average Event Notification is half a minute late while most requests return nothing at all. A webhook delivers the fact when it happens, so integrations react immediately and the provider is not answering thousands of empty queries. The cost is that you now operate a public endpoint that must be secure, fast and tolerant of duplicates.

How do you verify a webhook is genuine?

With a signature over the raw request body. Event Notifications should carry an HMAC-SHA256 header computed with a shared secret; the receiver recomputes it and compares in constant time before parsing anything. Verifying after parsing is a mistake, because JSON re-serialisation changes bytes and breaks the comparison. A timestamp in the signed payload additionally stops an old captured request being replayed.

What should a webhook handler do first?

Almost nothing. An Event Notification endpoint should verify the signature, persist the raw payload, return 2xx, and hand the work to a background job. Doing real processing inline makes the provider's timeout your outage: slow handlers get retried, retries pile up, and the queue on their side backs up. Fast acknowledgement plus asynchronous processing is the pattern that survives load.

How do you handle duplicate deliveries?

By treating them as certain. Webhooks & Event Notifications are delivered at least once, so the same event will arrive twice whenever an acknowledgement is lost. Recording the provider's event identifier and ignoring anything already processed makes the handler idempotent. Without that, a retried payment notification credits an account twice, and the bug only appears under exactly the network conditions that are hardest to reproduce.