Stop Polling, Start Listening

A lot of the integrations I inherit look like this: every five minutes, forever, a script wakes up and asks the third-party system "what's the status of everything right now?" It compares that snapshot to the last snapshot, guesses at what must have changed, and updates your system accordingly.

It works, mostly. It's also the slow, expensive way to do this, and it gets the story wrong more often than people realize.

A snapshot isn't the same as a fact

If you poll and see an order went from "processing" to "shipped," you know the current state. You don't know when it shipped, whether it shipped twice and got corrected, or whether it briefly went to "cancelled" and back before your next poll caught up. You've got the medal, not the race.

Most of the "why doesn't this number match" tickets I get called in to debug come down to exactly this: two systems each holding their own snapshot of "current state," polled on different schedules, quietly drifting apart. Nobody lied. Nobody has the full history either.

What changes when you listen instead

An event is a fact: OrderWasShipped, InvoiceWasPaid, CustomerAddressWasUpdated. It's timestamped, it's in the past tense, and once it happened, it happened — there's nothing to reconcile against a later poll.

When a vendor supports webhooks (most of the platforms I connect to — Restaurant 365, Dynamics 365, plenty of others — do, to varying degrees), the integration stops asking "what's true right now?" and starts recording "what just happened." That has real, practical consequences:

• You get things closer to real time, without hammering a rate-limited API every few minutes to find out nothing changed.
• You get an audit trail for free, because the event log is the history — no more "well, according to our system it happened Tuesday" arguments.
• Replays get cheap. If your downstream system was down for an hour, you replay the events it missed instead of trying to reconstruct a diff between two snapshots.

Where I still poll anyway

Not every vendor gives you a choice. Plenty of platforms — especially older ERPs and anything still exporting nightly CSVs to an SFTP drop — don't have an event to listen for. In those cases polling isn't a design mistake, it's the only door available, and the discipline is in narrowing what you poll for and how you turn "I saw a difference" into an event of your own before it reaches the rest of your systems.

The point isn't that polling is always wrong. It's that when a vendor gives you the choice, an event you can listen for beats a snapshot you have to interrogate, almost every time.