On this page
What webhooks do
A webhook is an HTTP request one system sends to another when something happens: a payment succeeds, an order ships, a lead is created, a document is signed. Instead of the other system asking “anything new?” every few minutes, it’s told the moment the event occurs. Webhooks are how payment gateways, CRMs, messaging platforms and many SaaS tools keep other systems up to date.
The idea is simple, but reliability isn’t. Networks fail, receivers go down for maintenance, events arrive out of order or more than once. A webhook system that doesn’t plan for this will lose events or process them twice — and in payments or orders, both are costly.
Who needs it
- An e-commerce store receiving payment, refund and shipping events from its gateway and courier.
- A SaaS startup offering webhooks so customers can connect the product to their own systems.
- A real estate portal notifying brokers’ CRMs the moment a new enquiry arrives.
- A clinic receiving booking confirmations or message delivery status from a messaging provider.
- A manufacturer alerting a distributor system when an order changes status.
Warning signs: orders that stay “pending” after payment, duplicate emails when a provider retries, events lost during a deployment, or no way to tell whether a customer’s endpoint has been failing for days.
What’s included
When you send webhooks
- Signed payloads (for example, an HMAC signature header) so receivers can verify the event came from you.
- Automatic retries with exponential backoff when a receiver fails or times out.
- A searchable delivery log with the ability to replay any event.
- Endpoint health tracking, with notifications when a subscriber keeps failing.
- Event versioning and documentation of every payload.
When you receive webhooks
- Signature verification for every incoming event, rejecting anything unsigned or invalid.
- Idempotent processing using event IDs, so a retried or duplicated event is handled once.
- Quick acknowledgement with processing moved to a background queue, so the sender doesn’t time out.
- Handling of out-of-order events by checking current state before acting.
How we build it
- List the events that matter and what each receiving system should do with them.
- Design payloads and signatures, keeping payloads small and stable, with an event ID and timestamp on each.
- Build the delivery or receiving pipeline with a queue, retries and logging.
- Test the failures — receiver downtime, slow responses, duplicate deliveries and events arriving out of order.
- Monitor after launch, with alerts for growing retry queues and consistently failing endpoints.
Why “effectively exactly once” matters
Over an unreliable network, a sender can’t know for certain whether a receiver processed an event, so reliable systems deliver at least once and retry when unsure. That means receivers must expect duplicates. By recording each event ID and ignoring ones already processed, the receiver turns at-least-once delivery into effectively exactly-once behaviour — no double shipments, no duplicate confirmation emails, even during an outage and recovery.
What affects timeline and cost
- Whether you’re sending, receiving, or both.
- The number of event types and how many external senders or subscribers are involved.
- Volume and how quickly events must be processed.
- Whether subscribers need a self-service dashboard to manage endpoints and view deliveries.
- How your existing system handles background jobs and queues.
We scope the work once the event list is agreed, and share an estimate before building starts.
Common mistakes
- Accepting webhooks without verifying signatures, so anyone can fake an event.
- Processing the same event twice because duplicates weren’t expected.
- Doing slow work before responding, causing timeouts and more retries.
- No delivery log, so nobody can prove whether an event was sent or received.
- Failing endpoints that go unnoticed for weeks.
Frequently asked questions
What’s the difference between a webhook and an API?
With an API, your system asks another system for data. With a webhook, the other system tells yours when something happens. Most integrations use both: webhooks for timely notifications, and API calls to fetch full details or confirm state.
What happens if our server is down when a webhook arrives?
Most well-built senders retry for a period. On our side, receivers are designed to process retried events once, and where the sender offers it, missed events can be fetched or replayed after recovery.
Can you add webhooks to our SaaS product for customers to use?
Yes — including signed payloads, retries, a delivery log and documentation, and optionally a dashboard where customers can manage their endpoints and replay events.
How do receivers verify our webhooks are genuine?
Each payload is signed with a secret shared with that subscriber. The receiver recomputes the signature and rejects any request that doesn’t match, and a timestamp helps prevent old requests being replayed.
Can you fix a webhook integration that keeps missing events?
Yes. We check the delivery and receiving logs, find where events are dropped or duplicated, and add the missing pieces — usually signature checks, idempotency, background processing or a reconciliation job.
Talk to us about webhook development
Event delivery with retries, signature verification and a replay log for failures.