Choosing between webhooks, polling and file drops for EPOS data
Dave Lyons, Founder, RED EPOS · 2026-09-23
Every custom integration comes down to the same question: how does data actually move between your till and the other system? There are three practical answers — webhooks, polling and file drops — and each fits a different kind of job. This is a plain explanation of how they work, in prose only; we don’t run a live demo of any of them here (that’s deliberately out of scope for this article).
Webhooks: the other system tells you
A webhook is a callback. You give the other system a web address, and when something happens on their side — an order comes in, a payment settles — they send your endpoint a message straight away. Deliveroo’s own developer platform works this way: it lets you configure a webhook to receive order and rider events in real time, rather than the integrator having to ask for updates itself (Deliveroo, API documentation).
The upside is speed and efficiency — you find out the moment something happens, and you aren’t making requests that come back empty. The cost is that you need somewhere permanent, secure and publicly reachable to receive them, and you have to handle the messy realities of delivery: most providers send “at least once”, so the same event can arrive twice, and a handler that isn’t built to cope with a repeat will double-process it. Stripe’s own guidance is blunt about it: verify that the message really came from who it claims to, and store the ID of everything you’ve already handled so a repeat delivery is a no-op rather than a duplicate charge or a duplicate stock movement (Stripe, “Receive Stripe events in your webhook endpoint”).
Polling: you ask, on a schedule
Polling is the opposite: your system asks the other one “anything new?” on a timer, whether or not there’s anything to report. It’s simpler to build — you don’t need a public endpoint, just a scheduled job with an HTTP client — which makes it the natural choice when the other system doesn’t offer webhooks at all, or when a short delay between an event happening and your till picking it up genuinely doesn’t matter.
The trade-off is waste and lag, and the two pull against each other. Poll every five minutes and your average delay before your till sees a change is two and a half minutes; poll every thirty seconds instead and you cut that lag, but you’re now making around 2,880 requests a day to catch perhaps a handful of real events, almost all of them coming back empty — a cost that scales with every extra system you poll, and one that can run into a provider’s own rate limit if you push it too hard (ByteByteGo, “Polling vs Webhooks”).
File drops: a scheduled handover
The third pattern doesn’t call an API at all: one system writes a file — a nightly sales export, a stock update — to a shared, secure location (typically SFTP), and the other picks it up on its own schedule. It’s the oldest of the three patterns and still a common one for back-office data that doesn’t need to move in real time: end-of-day totals into an accounting system, a supplier’s price list into stock, a batch of transactions into a reporting warehouse. It suits systems that were never built with a modern API in the first place, and it keeps both sides loosely coupled — nobody has to be online and listening at the exact moment the file lands (Commport, “EDI via SFTP”).
The trade-off is the same as polling’s: nothing is real time, and a bad or late file can sit unnoticed until someone checks it, so the job needs its own monitoring — something has to flag a file that didn’t arrive, not just wait for someone to notice the sales figures look wrong.
How we choose
We look at three things: how quickly the other side actually needs to know, what the other system already supports (plenty of hospitality and retail back-office software still doesn’t offer webhooks), and how much ongoing operational weight you want to carry. A payment or a live delivery order needs a webhook — the delay of polling isn’t acceptable and the volume doesn’t justify a batch file. An overnight accounts sync is usually happier as a scheduled file drop — simpler, and nothing is lost by it running once a day. Polling sits in between: useful when a partner has no webhook to offer but the data still needs to move faster than daily.
Whichever pattern we build, the same checks from how AI coding agents change what a small integrator can build apply: the spec for what should happen on a duplicate or a late delivery is a decision, not a guess; the endpoint or file location is secured properly; and it’s tested against your real till before it goes live. For how these mechanisms map onto ICRTouch’s own products specifically, read ICRTouch’s developer interfaces explained, or start from what an EPOS integration actually is if you’re new to the topic. For the systems we’ve already built links for, see the integrations directory; for the wider picture, see our integrations and AI page.