™2 min read
The trade-off
| Webhooks | Polling | |
|---|---|---|
| Latency | Seconds | Up to your poll interval |
| Request cost | None (push) | Every poll counts against the rate limit |
| Needs an endpoint | Yes (public HTTPS) | No |
| Handles missed events | Retries + replay | Naturally re-reads state |
Use both
React to webhooks in real time, and run an occasional reconciliation poll to catch anything missed during an outage past the 72-hour retry window. See Replay and recover missed webhooks.
Frequently asked questions
I cannot host an endpoint — what do I do?
Poll the relevant read endpoint on a sensible interval and cache aggressively to stay under the rate limit. See Recover from rate limits.
Is polling ever better?
For low-frequency, non-urgent sync where hosting an endpoint is not worth it. Otherwise webhooks win on latency and cost.
How do I combine the two without double-processing?
Run webhooks as the primary path and a periodic reconciliation poll as the safety net, and route both through the same idempotent handler keyed on the resource. The poll then only ever fills genuine gaps left by an outage, and anything the webhook already applied is a harmless no-op.
Funding for UK limited companies
Credicorp lends to your company, not to you personally — short-term working capital with no personal guarantee. See what your business could access.