Webhooks vs Polling: Which approach should you choose?

When an application needs to detect a change in an external system, two approaches dominate: polling, which regularly queries an API, and webhooks, where the remote system sends a notification as soon as an event occurs.

Both address the same need, but with very different trade-offs in terms of latency, server load, and complexity. The right choice depends on the API's capabilities and your technical constraints.

There are also other approaches, such as file-based interfaces (CSV, JSON, XML, etc.). Still used in some systems, they are nevertheless much more archaic than APIs, so we will not discuss them here.

What is polling?

Polling is very simple in principle: it consists of regularly querying an API to check whether new data is available.

For example, your application can call the API every 30 seconds, providing the date or cursor corresponding to the last piece of data retrieved:

GET /api/orders?since=2026-08-25T10:00:00

The API then returns the new orders, or simply indicates that no changes have occurred. The drawback is obvious: most requests may return nothing new. If you query an API every 30 seconds and no changes occur for several hours, you are still sending several unnecessary requests.

What is a webhook?

With a webhook, the process is reversed. Instead of regularly asking the other system whether something has changed, you provide it with a URL that it can call when an event occurs.

The request could look like this:

POST /webhooks/order
Content-Type: application/json

{
  "event": "order.created",
  "order_id": 12345,
  "customer_id": 987
}

Your application is therefore generally informed very quickly after the event, without having to constantly query the API.

Webhook vs Polling: The main differences

Polling is therefore generally simpler, although this can be debated, while webhooks allow you to react much more quickly and avoid many unnecessary requests.

When should you use polling?

Polling remains a very good solution in many cases.

The API does not provide webhooks

This is probably the most obvious reason: if the remote service does not provide webhooks, then webhooks are simply not an option. You have no choice; you will have to regularly query its API.

This is still common with some older APIs or services that only provide standard REST endpoints.

Real-time is not necessary

If a delay of a few minutes is not a problem, it is not necessarily necessary to implement an event-based architecture. For example, if you need to synchronize data every hour, a simple job that queries the API may be more than sufficient.

Your application cannot receive incoming connections

A webhook generally requires the provider to be able to contact your application. This can be complicated if your application is behind a firewall or infrastructure that does not accept incoming connections.

With polling, your application only needs to make outgoing requests.

You need a full synchronization

Polling can also be useful when you need to regularly retrieve the complete state of a resource rather than simply receive event notifications.

For large amounts of data, however, it is preferable to use incremental synchronization with a cursor, token, or modification date rather than downloading all the data on every run.

When should you use webhooks?

Webhooks are particularly useful when the response needs to be fast.

Payments

Imagine that a user makes a payment. With polling, your application regularly queries the server to check whether the transaction has been validated, which introduces a delay and generates unnecessary requests.

With webhooks, the payment server immediately sends a notification as soon as the payment is confirmed. Your application can therefore react in real time, without waiting for the next check.

Notifications

Webhooks are also suitable for events such as:

• user creation;
• new order;
• invoice modification;
• subscription change;
• package delivery;
• new support ticket.

In all these cases, the application does not need to constantly ask whether something has happened.

The main problem with webhooks: Reliability

Webhooks seem very simple, but putting them into production requires more work than a simple API call. What happens if your server is temporarily unavailable? What happens if the provider sends the same event twice? Or if events arrive in the "wrong" order?

A webhook should therefore not be considered a message that will arrive exactly once and in the correct order. Some providers may make several attempts when your endpoint does not respond correctly, and events may be received multiple times (hence the importance of handling IDs).

Idempotency is important

Suppose you receive:

{
  "event": "payment.completed",
  "payment_id": 123
}

If you create an invoice every time the webhook is received and the same event is sent twice, you may end up creating two invoices. Your application must therefore be able to recognize that an event has already been processed.

One solution is to store the event's unique identifier:

Event ID: evt_12345
        |
        v
Already processed?
   /          \
 Yes           No
 |              |
Ignore        Process
                 |
                 v
           Store ID

Webhooks must also be secured

A webhook endpoint is generally accessible from the Internet. You should therefore not simply trust every request received at this URL.

Depending on the provider, webhooks can be secured using a cryptographic signature, a shared secret, dedicated authentication, or, when possible, a list of allowed IP addresses.

Signature verification helps ensure that the request actually comes from the expected service. It is also preferable to use HTTPS (Nowadays, this should not even be a question...).

Do not do all the processing in the webhook

Another common problem is doing too much work before responding to the provider.

For example:

Webhook received
   |
   +-- Verify payment
   +-- Update database
   +-- Generate PDF
   +-- Send email
   +-- Call another API
   |
   v
HTTP 200

If all these operations take several seconds, the provider may consider that your endpoint did not respond correctly and make another attempt.

The best practice is to accept the event quickly, then perform the processing in a queue or worker:

Webhook
   |
   v
Store event
   |
   v
HTTP 200
   |
   v
Queue
   |
   v
Worker
   |
   +-- Database
   +-- Email
   +-- External API

This also makes it easier to handle periods when many events arrive simultaneously.

Polling can also have its problems

Polling is simpler, but that does not mean you should implement it without thinking. Polling every 5 minutes may seem reasonable. But if you have 10,000 clients, each making a request every 5 minutes, that represents:

10,000 × 12 × 24 = 2,880,000 requests / day

And a large proportion of these requests may detect no changes. You therefore need to take into account the number of clients, the polling frequency, and the limits of the remote API. Polling too frequently can also result in 429 Too Many Requests errors.

Incremental synchronization can also considerably reduce the amount of data transferred.

Why not use both?

In some systems, the best solution is to combine both approaches.

Webhooks are used to get changes quickly, while periodic polling can be used to check that no events have been missed. This approach allows you to benefit from the low latency of webhooks while still having a recovery mechanism in case an event is missed.

So, which one should you choose?

There is no universal answer.

Use webhooks if:

• you need to react quickly to an event;
• the provider offers reliable webhooks;
• you can expose an HTTPS endpoint;
• you want to avoid many unnecessary requests;
• your application is event-based.

Use polling if:

• the service does not provide webhooks;
• a delay of a few minutes or hours is acceptable;
• your infrastructure cannot receive incoming connections;
• you need to periodically synchronize a set of data;
• simplicity is more important than low latency.

And in systems where missing a change is important, combining both can be an excellent solution.

Conclusion

Webhooks and polling both allow you to detect changes in a remote system, but they address different needs.

The era is real-time: webhooks are the way to go in this type of scenario.

It's up to you to make the right choice!