What is the difference between a webhook and an API?

Direction. With an API you make a request when you want data. With a webhook the other system makes a request to you when something happens. Webhooks are push; APIs are pull.

How do I test a webhook locally?

Use a tunnelling tool to expose your local server on a public URL, or a request-inspection service to capture the real payload first and replay it against your handler.

Why is my webhook being called multiple times?

Most providers deliver at least once and retry on any non-2xx response or timeout. If your handler is slow or errors after doing its work, you will see duplicates — make the handler idempotent and acknowledge quickly.

Only if you verify them. Use the provider signature with a shared secret, require HTTPS, and reject unsigned requests. An unverified endpoint accepts anything anyone posts to it.

What Is a Webhook? How They Work and How to Debug Them

What is a webhook?

A webhook is an HTTP request one system sends to a URL you supply, the moment an event happens. Instead of you repeatedly asking "has anything changed?", the source tells you. It is the difference between checking your mailbox every five minutes and having post delivered.

Webhook vs polling

	Webhook	Polling
Latency	Immediate	Up to the interval
Wasted requests	None	Most checks find nothing
Setup	Needs a public URL	Just credentials
Missed events	Possible if you're down	Caught on next poll

Webhooks win on speed and efficiency. Polling wins on simplicity and resilience — if your service is down during a poll cycle, you catch up next time; if it is down when a webhook fires, that delivery may be lost unless the sender retries.

What you must handle

A webhook endpoint is a public URL receiving untrusted input, and there are four things that catch people out.

Verify the signature. Most providers sign the payload with a shared secret. Without verification, anyone who learns your URL can post fabricated events. This is the single most-skipped step.

Respond fast, process later. Senders usually time out in a few seconds and treat a slow response as a failure. Acknowledge with a 200 immediately, then do the work asynchronously. Doing the processing inline is why endpoints get hammered with retries.

Expect duplicates. Delivery is usually at-least-once, so the same event can arrive twice. Handlers must be idempotent — processing an event twice should have the same effect as processing it once. Key on the event ID.

Do not assume order. Events can arrive out of sequence. If order matters, use timestamps or sequence numbers in the payload rather than arrival order.

Debugging

The awkward part of webhooks is that you cannot easily trigger them from your own machine. The usual approach:

Use a request-inspection endpoint to see the real payload shape
Tunnel to localhost for development
Log every received payload before parsing — when something breaks, the raw body is what you need
Check the sender's delivery log, which usually shows attempts and response codes

Common failure modes

Returning a non-2xx by accident. Any error status triggers retries. A handler that throws on an unexpected field turns one event into a retry storm.

No retry handling on your side. If a downstream system is briefly unavailable, the event is lost unless you queue it.

Silent signature failures. Rejecting unsigned requests is correct; doing it without logging means genuine misconfiguration looks identical to an attack.

Thousands of ready-made workflows start from a webhook. Import one and adapt it rather than wiring the plumbing yourself.

Browse webhook-triggered workflows

Frequently asked questions

What is the difference between a webhook and an API?: Direction. With an API you make a request when you want data. With a webhook the other system makes a request to you when something happens. Webhooks are push; APIs are pull.
How do I test a webhook locally?: Use a tunnelling tool to expose your local server on a public URL, or a request-inspection service to capture the real payload first and replay it against your handler.
Why is my webhook being called multiple times?: Most providers deliver at least once and retry on any non-2xx response or timeout. If your handler is slow or errors after doing its work, you will see duplicates — make the handler idempotent and acknowledge quickly.
Are webhooks secure?: Only if you verify them. Use the provider signature with a shared secret, require HTTPS, and reject unsigned requests. An unverified endpoint accepts anything anyone posts to it.

Polling: Checking a service for new data on a schedule (e.g., every 5 minutes). Simpler than webhooks but slower and rate-limit-hungry.
API (Application Programming Interface): A defined way for software to talk to other software. Automation platforms are essentially friendly wrappers around thousands of APIs.
Trigger: The event that starts an automation — a new email, a form submission, a webhook call, or a schedule. Every workflow begins with exactly one trigger.
Idempotency: Designing steps so running them twice has the same effect as once. Critical for automations that may retry after partial failures (e.g., avoid double-charging).
Error handling: Workflow branches that catch failures — retries, fallback paths, alert notifications — so one bad record does not silently kill a business process.