Webhooks feel modern and polling feels dated, but the right answer depends on what happens when a delivery is missed — and every webhook system misses deliveries eventually.
Webhooks give latency, not guarantees
A webhook is an HTTP request to your endpoint, retried a few times with backoff. If your service is down for longer than the retry window, or returns 500 consistently, the event is dropped unless the sender keeps a replayable log. Latency is excellent, guarantees are not.
Polling gives completeness, not speed
Polling an endpoint for messages since a cursor is boring and reliable: you control the pace, you can replay, and an outage costs you delay instead of data. The cost is a constant trickle of requests and a latency floor equal to the poll interval.
The combination that works
Webhook for latency, poll as reconciliation. On each webhook, enqueue the message id; run a periodic poll that asks for anything newer than the last processed id and fills the gaps. The poll makes the system correct, the webhook makes it fast.
One detail that makes reconciliation cheap
Make the cursor the message id, not a timestamp. Timestamps collide at second granularity and drift between clocks, so a poll built on them either re-fetches or skips messages. A monotonic id gives you exact resume semantics.
Volanea delivers inbound mail by webhook and also exposes a cursor-based read endpoint, so reconciliation is a loop instead of a guess.
Top comments (0)