Webhooks Explained for Business Integrations

By Grocito16 October 2026

A webhook is an HTTP callback: when something happens in one system, such as a payment succeeding or a form being submitted, that system immediately sends a message to a web address you control. Compared with polling, where you keep asking "anything new?", webhooks are faster and cheaper. To run them safely, verify signatures, handle duplicates and retries, and answer quickly.

Key takeaways

A webhook pushes an event to you when it happens, so you do not need to keep asking for updates.
Treat webhooks as unreliable delivery: messages can arrive twice, late or out of order.
Verify the signature, use HTTPS and never trust the payload blindly.
Respond quickly, then do the heavy work in the background.
Log everything, monitor failures and plan for payload changes over time.

What is a webhook?

A webhook is a message that one application sends to another when an event occurs. Technically it is an ordinary web request, usually a POST with data in the body, sent to a URL that you register in advance. You may hear it called a reverse API or an HTTP callback, because instead of you calling the other system, the other system calls you.

Common examples include:

A payment provider telling your store that a payment succeeded or failed.
A form tool telling your CRM that a new enquiry arrived.
A shipping platform telling your shop that an order has been dispatched or delivered.
A support tool telling your messaging app that a ticket was updated.

How do webhooks differ from polling and APIs?

APIs

A normal API request is you asking for something: give me this order, create this contact. You start the conversation.

Polling

Polling means calling an API repeatedly to see whether anything has changed. It is simple but wasteful. Most requests return nothing new, and there is always a delay until the next check.

Webhooks

The other system starts the conversation only when something changes. You get near-instant notice with far fewer requests. Webhooks and APIs usually work together: the webhook says "order 123 changed", and your system calls the API to fetch the full, current details. For wider context, read our guide on API integration for business.

How does a webhook flow work step by step?

Event: something happens in the sending system, such as a payment succeeding.
Payload: the sender builds a message describing it, usually in JSON, with an event type, an identifier, a timestamp and the relevant data.
Signature: the sender signs the message with a shared secret so you can check it is genuine and unchanged.
Delivery: the sender sends an HTTPS request to your registered endpoint.
Verification: your endpoint checks the signature and basic validity.
Acknowledgement: your endpoint replies with a success status quickly, telling the sender you received it.
Processing: your system does the real work, ideally in the background.

If the sender does not receive a success reply, it assumes delivery failed and tries again later.

How do you make webhook handling reliable?

Assume that delivery is "at least once", not "exactly once".

Retries

Senders usually retry failed deliveries on a schedule that gets slower each time, and give up after a while. Your endpoint should be ready for the same event to arrive again, and also for a burst of queued events after you recover from downtime.

Idempotency

An operation is idempotent if doing it twice has the same effect as doing it once. Store the unique event identifier, and before processing check whether you have already handled it. If so, acknowledge it and do nothing. This prevents a duplicate event from creating two orders or sending two emails.

Ordering

Events can arrive out of order. An "order updated" message might land before "order created". Do not assume order. Use timestamps or version numbers in the payload, or fetch the latest state from the sender's API when an event arrives, so an old event cannot overwrite newer data.

Timeouts

Senders wait only a short time for your reply. If your handler does slow work such as generating documents or calling other services, it may time out and trigger a retry. Acknowledge fast, put the job in a queue and process it separately.

Dead-letter handling

Some events will fail repeatedly because of a bug, bad data or a downstream outage. Move them to a dead-letter store rather than losing them or retrying forever. Alert someone, fix the cause and replay the stored events.

How do you secure a webhook endpoint?

Your endpoint is a public door, so anyone can send requests to it.

Verify signatures: compute the expected signature from the raw request body and your shared secret, compare it safely, and reject anything that does not match. Check any timestamp to reduce replay of old messages.
Use HTTPS only, so payloads cannot be read or altered in transit.
Rotate secrets on a regular schedule and straight away if one may have leaked. Support two active secrets briefly so rotation causes no downtime.
IP allow-lists are an optional extra layer if the sender publishes its addresses, but never your only protection, because addresses change.
Never trust the payload blindly. Validate its structure, and for important actions such as marking an order paid, confirm the facts by calling the sender's API directly.

Our API security checklist lists more controls that apply here.

How should you design webhooks for your own customers?

If your product lets customers connect their own systems, you are the sender, and your design choices become their problem or their delight.

Event catalogue: document each event type, when it fires and an example payload.
Stable identifiers: give each event a unique ID and include a timestamp and version.
Signing: sign every request and explain exactly how to verify it, with sample code in common languages.
Retries: use sensible backoff, document the schedule and tell customers what counts as success.
Delivery logs: let customers see recent deliveries, response codes and errors, and resend an event with one click.
Self-service controls: let them add and disable endpoints, choose which events they receive and rotate secrets.

If you plan to offer integrations to your own users, our API development services can help you design them.

How do you test and debug webhooks?

Sandbox or test mode: most providers offer a way to trigger test events without real transactions.
Request inspection tools: a temporary public address that records incoming requests lets you see exactly what is sent while developing locally.
Replay: the ability to resend a past event makes debugging and recovery much easier.
Logs: record the event ID, type, time received, signature result, processing outcome and any error. Do not log secrets or unneeded personal data.
Failure drills: test duplicates, out-of-order events, a wrong signature and an outage.

How do no-code platforms use webhooks?

No-code and automation platforms commonly start workflows from a webhook: a form submission arrives, the platform adds a row to a sheet, creates a CRM record and sends a message. This is a fast way to connect tools, and a good fit for simple, low-risk flows. Be mindful that retries, error handling and duplicate protection may be basic. For critical flows such as payments, a custom endpoint with proper checks is often safer. See our guide to business process mapping before you automate.

What should you monitor?

Number of events received, processed and failed.
Signature failures, which may indicate a misconfigured secret or an attack.
Time between event creation and processing.
Size of the retry and dead-letter queues.
Silence. If a source that normally sends events goes quiet, something may be broken.

How do versioning and payload changes work?

Senders add fields and sometimes change behaviour. Ignore fields you do not recognise and read the version field if there is one. When you publish webhooks, announce changes early, add fields without removing old ones and give customers a migration period.

A short worked example

Imagine a small online shop. A customer pays, then closes the browser before the confirmation page loads. The provider sends a "payment succeeded" webhook. The shop checks the signature, sees the event ID is new, replies success at once and queues the order update. When the provider retries because its first attempt looked slow, the shop sees the same event ID and does nothing. The order is marked paid exactly once.

What mistakes should you avoid?

Skipping signature verification because "it works in testing".
Doing slow work before responding, which causes timeouts and duplicate deliveries.
Assuming exactly-once, in-order delivery.
Treating the redirect or browser as proof of payment instead of the webhook.
Having no logs, replay or alerting.

FAQ

What is a webhook in simple terms?

A webhook is an automatic message one system sends to another when something happens, such as a new order or a successful payment. It is delivered as a web request to an address you provide, so you hear about events immediately without checking for them.

What is the difference between a webhook and an API?

With an API, your system asks another system for data or to do something. With a webhook, the other system tells your system when an event occurs. Most integrations use both: the webhook gives the alert and the API provides the full details.

How do I know a webhook is genuine?

Check the signature that the sender includes with each request, using the shared secret and the raw request body, and reject anything that does not match. Also use HTTPS, check timestamps where provided and confirm important facts through the sender's API before acting. Our API development team can help you set this up properly.

What should I do if my webhook endpoint was down?

Most providers retry for a period, so some events will arrive when you recover, and many also let you replay missed events from a dashboard. Make your handler idempotent, check the provider's delivery log and reconcile your records against theirs so that nothing is missed.

Next steps

List every webhook your business receives, including those hidden in no-code tools, and check each one for signature verification, duplicate handling and logging. Add alerts for failures and silence. If you would like help building or reviewing integrations, contact us and we can go through your setup with you.