POS Integration Development: How Restaurants and Retailers Connect Their Tech Without Breaking Operations

An operations director running 25 locations has a Toast terminal at every counter, Wolt live in every city, and a loyalty app the marketing team is proud of. Each of the three works fine on its own. The problem shows up the moment a menu item changes: someone has to update it in Toast, then in Wolt, then in the loyalty app — 25 times, three systems each. Miss one location, and a guest orders a dish that's been sold out since Tuesday.

That's not a tooling problem. It's a missing integration layer, and it's the single most common reason restaurant and retail chains outgrow their POS setup faster than they expected to.

This article covers what POS integration development actually involves as an engineering task: the webhook-versus-polling decision that shapes everything downstream, why duplicate events are the default behavior of any distributed system (not a bug), how menu synchronization breaks in three predictable ways, what the real POS API landscape looks like once you're past the sales deck, and — honestly — when you don't need custom development at all.

Off-premises orders now account for 75% of all restaurant traffic, according to the National Restaurant Association's 2025 State of the Industry data, and 65% of limited-service operators already offer delivery. Every one of those channels needs to talk to the POS. The volume of that traffic is exactly what turns a manual workaround into an operational risk.

After building POS integrations with Toast, Square, Syrve, and other systems across 70+ FoodTech projects, one thing holds regardless of which POS is on the counter: the API connection itself is rarely the hard part. Designing for failure is — because at a restaurant during peak hour, failures aren't hypothetical.

POS integration development is the process of building a reliable data connection between a POS system and other operational software — delivery platforms, loyalty programs, inventory systems — so that transactions, menu changes, and inventory movements flow automatically, without someone re-typing them into a second screen.

In practice, it covers three recurring scenarios:

1. POS to delivery platforms. Orders placed on aggregators land in the POS automatically, menu updates flow in both directions, and order status changes propagate back to the customer in real time.
2. POS to loyalty. Every transaction triggers a points calculation, supports partial redemption, and updates a customer's balance immediately — not at end-of-day batch close.
3. POS to ERP or inventory. Each sale becomes a journal entry; sold items deduct ingredients according to the recipe, not just the finished dish count.

None of these are hard in isolation. What makes the work harder than the sales pitch suggests is the environment they run in: restaurant Wi-Fi that drops mid-shift, several orders landing in the same second during dinner rush, POS vendors shipping API changes without a changelog, and every aggregator formatting its menu payload slightly differently. A seamless workflow built around your POS has to account for all four before it ever reaches production.

The restaurant technology stack that's become standard in 2026 already assumes these systems are connected — the harder question, covered below, is exactly how that connection should be built. And before any of that, it helps to know what data your POS is already generating that an integration can put to work.

The first decision in any POS integration determines latency, load on the POS API, and how much failure-handling code you'll need to write. There are two ways to move.

Webhook: the POS sends an HTTP POST to your system the moment something happens — a new order, a completed payment. Reaction time is measured in seconds. It requires a public HTTPS endpoint on your side and code that handles the same event arriving more than once.

Polling: your system asks the POS API "anything new?" on a schedule — every 15, 30, or 60 seconds. Simpler to build, no public endpoint required, but latency is bounded by however often you ask.

The practical rule: webhooks for anything time-sensitive — new orders, payment confirmations — and scheduled polling or incremental sync for menu and inventory data, where a 5-minute lag is tolerable. Most production integrations run both patterns side by side rather than picking one.

One detail that surprises teams building their first POS integration: a webhook can arrive twice for the same event. If your endpoint doesn't return an HTTP 200 fast enough, the POS assumes delivery failed and retries. That's not a bug in the POS — it's the entire reason the next section exists.

Ghost kitchens running several brands out of one kitchen deal with an amplified version of this same problem, since order routing across multiple concepts depends on the same webhook infrastructure staying reliable under load.

Online Orders Without Downtime: How Restaurants and Retailers Can Ensure Stability and Growth

Duplicate orders during a busy Friday shift aren't a "maybe someday" risk — they're the default outcome of an integration without retry logic.

Read the article

When a connection is unstable, the POS resends a webhook it thinks failed. Without a way to recognize "I've already handled this one," that retry becomes a second ticket in the kitchen, a second loyalty point award, and a second inventory deduction for a single sale.

Idempotency means an operation produces the same result whether it runs once or five times. The mechanism is straightforward: every event carries a unique event_id. Before acting on it, the system checks whether that ID has already been processed. If yes, it acknowledges the webhook and does nothing further. If no, it processes the event and records the ID.

The usual implementation stores processed_event_ids in Redis with a 24–48 hour TTL — fast lookups, and old IDs expire automatically instead of accumulating forever.

Where this matters most in a restaurant context:

• Loyalty. A duplicate point award doesn't announce itself. It surfaces weeks later during a reconciliation audit, after it's already affected margin.
• Inventory. A duplicate deduction throws off shrinkage numbers for the whole shift, and nobody notices until the count doesn't match sales.
• Delivery status. A duplicate "ready for pickup" event can send a courier to the same order twice.

Beerpoint, a loyalty app dev.family built for a beverage retail chain, is a useful real-world reference for what this looks like at scale. The chain grew from 189 to 211 stores after the loyalty program launched, and the app now serves 385,000+ active users who've completed more than 4 million purchases through it. The catalog and pricing sync from the POS on a roughly 15-minute refresh, and the stack runs on Redis alongside PostgreSQL and Laravel — exactly the kind of fast, TTL-based store that makes idempotency checks practical at that volume. At 385,000+ users, an unguarded duplicate-event bug wouldn't stay small for long.

The same logic that keeps loyalty transactions honest is what keeps reservation and POS data in sync once a franchise is running the program across multiple locations instead of one.

Why Loyalty Programs Fail in Restaurant Franchises – and How to Build One That Works Across Locations

A loyalty program that quietly double-counts points doesn't look broken — until an audit six months in shows the numbers don't add up.

Read the article

Menu synchronization between the POS and everything downstream is the technically hardest part of most integrations — not because the concept is complex, but because every aggregator enforces its own format, rate limits, and update rules.

Full sync on a schedule. The entire menu gets rewritten once or a few times a day. Simple to build, and it guarantees consistency at each sync point. The downside: no real time. Pull an item at 2 p.m., and the aggregator won't know until the 2 a.m. sync.

Incremental sync. The POS maintains a changelog of what changed; the integration pushes only the delta every 5–15 minutes. Faster and lighter than a full rewrite, but it depends on the POS actually exposing a changelog — not every system does.

Event-driven sync. The POS fires a menu_item_updated event the instant something changes. Real time, but it requires webhook support for menu-specific events — Toast and Square have it; legacy Oracle MICROS installations don't.

The three major US aggregators each have their own quirks worth knowing before you commit to an architecture:

• Wolt supports incremental PATCH updates through its Menu API and documents them well for partners.
• DoorDash requires the full menu object on every update — heavier payloads, more bandwidth, even for a one-item price change.
• UberEats offers partial updates through its Menu API, but partner certification requirements add lead time before you can go live.
• Grubhub runs its own API with its own idiosyncrasies, and needs separate handling from the other three.

The failure mode common to all three approaches, when implemented carelessly, is menu drift: the same item exists as a separate, unsynchronized copy in the POS, the website, and each aggregator. Someone updates it in one place, forgets the other three, and a guest orders a dish the kitchen can't make. The fix isn't a better sync schedule — it's an architectural principle. The POS menu is the single source of truth; every other system is a downstream consumer that reads from it, never the other way around.

Menu drift is also one of the more expensive failure modes to leave unaddressed, since it shows up directly as lost revenue on the delivery platforms restaurants depend on for off-premises volume, and it factors into the broader decision between building your own delivery channel and depending on aggregators.

Running three aggregators and still finding "sold out" items that sell anyway? Talk to us on LinkedIn or start a chat — tell us your current stack and we'll show you where the drift is coming from.

Anna S., Business Development Manager

Write in LiveChat

Write in LinkedIn

Not every POS is equally friendly to integrate with, and the system already installed usually decides more about your architecture than any preference you'd otherwise have. Here's what the landscape looks like from inside real projects, restricted to the systems that matter for the US market.

A few things worth knowing beyond the table: Toast is, in practice, the most integration-friendly option for the US market — most standard scenarios ship faster on it than on anything else here. Legacy Oracle MICROS and Aloha installs are the most expensive to work with; hearing "legacy Aloha" on a discovery call is a reliable signal to add 4–6 weeks and a different budget line. Revel Systems shows up often in franchise operations — quick-service and casual chains especially — and needs more custom logic than Toast or Poster to reach the same result.

One constant across every vendor here: POS providers update their APIs without warning, often without preserving backward compatibility. A production-grade integration validates incoming schemas and versions its handlers, rather than assuming this week's payload looks like last week's.

Most of what goes wrong in a POS integration is predictable if you know where to look — and none of it shows up in the API documentation.

1. API rate limits under real load. Toast's own developer documentation caps some endpoints — the menus endpoint, for one — at roughly one request per second per location, with a global ceiling of 20 requests per second across all APIs combined. Run 25 locations through dinner rush with a handful of events per minute each, and that ceiling stops being theoretical. The fix is an event queue with exponential backoff and jitter, not direct parallel calls hoping they all land.

2. POS API changes with no warning. Aggregators and POS vendors alike ship payload changes on their own schedule. Without schema validation on the way in, the failure is silent — data stops arriving correctly and nobody notices until a shift's worth of orders looks wrong in hindsight. The fix: validate every incoming schema and alert on anything unexpected, rather than trusting the shape stays constant.

3. Timezone and daylight saving edge cases. The restaurant sits in one timezone, the server in another, the aggregator reports everything in UTC. An order placed at 11:58 p.m. local time can land in the next business day on a report. Daylight saving transitions duplicate or drop an hour in daily totals twice a year. The fix: store everything in UTC at the database layer, and convert only at the point of display.

4. Partial failure inside a multi-step transaction. Loyalty points get credited, but the inventory service was down for 30 seconds and the deduction never happened. Now the books and the stockroom disagree, and nobody flagged it. The fix is a saga or outbox pattern for distributed transactions — not hoping every step in the chain stays up at the same time.

5. Menu item ID collisions after a POS re-import. A client re-imports their menu after a POS update, and internal item IDs change silently. Every downstream system — loyalty, inventory, every connected aggregator — that mapped against the old IDs breaks quietly. The fix: map against a stable external identifier (a SKU, a slug, a custom external_id) instead of the POS's internal ID, which was never meant to be permanent.

All five are solvable with the right architecture decided before the first line of integration code gets written — which is exactly why reservation systems that don't talk to the POS end up costing more in manual reconciliation than the integration would have cost to build properly the first time.

From Chaos to Control: Building Delivery Systems That Let Dark Kitchens Grow

A menu-sync fire drill across three locations shouldn't need to happen twice.

Read the article

Custom development isn't always the right call, and it's worth saying so plainly:

Skip custom when: you're on Toast plus one or two aggregators (its native integrations with Wolt, DoorDash, and UberEats plus middleware like Deliverect or Otter, roughly $300–500/month, cover it); you're on Square with basic loyalty needs (Square Loyalty is native); or you're running one location on standard systems, where SaaS middleware at $200–600/month beats a custom build over a 12-month horizon.

Custom earns its cost when: you're running three or more aggregators with different menu pricing per channel; you have ten or more locations needing centralized, real-time menu management; your loyalty program needs cross-location history and partial redemption — the Beerpoint scenario above; you're on a legacy POS that middleware doesn't support well; or you're a franchise that needs brand-level reporting and location-based access control generic middleware wasn't built for.

• POS integration is an architecture decision, not an API-connection task — webhook vs polling shapes everything that follows.
• Idempotency isn't optional once volume is real. Duplicate webhooks are normal system behavior, not an edge case.
• Menu drift is the most common and most expensive failure mode — fix it by making the POS the single source of truth, not by syncing harder.
• The POS you already have decides more about your integration architecture than any framework choice you'll make.
• Legacy POS versions (older Aloha, older Oracle MICROS) reliably add 4–6 weeks and a different budget to any project.
• Off-the-shelf middleware is the right call below a certain complexity threshold — custom development earns its cost above it, not before.
• All five common failure points are solvable if the architecture accounts for them before the first integration ticket is written, not after the first incident.