Every platform that needs POS data faces the same early decision: integrate broadly and shallowly across many systems, or integrate deeply with the one that matters most for your market and build from there. We picked the second path. Foodics first, before Square, before Toast, before any of the aggregator POS products. Here's why, what the depth-over-breadth decision actually required us to build, and what comes after.
Why Foodics
Market concentration, not brand preference. Foodics is the dominant POS in MENA fast-casual. In the UAE and Saudi Arabia — the two markets we entered first, the overwhelming majority of 3-to-50-location restaurant chains run Foodics. This is not a close call. When every Dubai pilot operator we spoke to in 2025 was on Foodics, the integration priority wrote itself. Building Habitu without a Foodics integration in MENA would be like launching a US restaurant loyalty platform without Square or Toast support — technically optional, practically disqualifying.
Operator pull accelerates integration quality. When your first operators are all on the same POS, every edge case they report is a Foodics edge case. Every data shape question, every modifier confusion, every sync timing complaint, all against the same system. That concentration of feedback is extremely valuable in the early months of an integration. If we'd spread that feedback across five POSes simultaneously, none of the integrations would have gotten deep enough to be reliable.
Foodics has real API depth. Not all POS APIs are equal. Some expose transaction totals and timestamps and call it an integration. Foodics exposes item-level order data, modifier groups, table assignments, branch-level configuration, and a webhook layer that makes near-real-time sync viable. That depth made a real two-way integration possible, not just reading transactions, but writing back loyalty state and syncing menu data in a form that operators can actually act on.
What "Deep Integration" Actually Meant to Build
Two-way sync, not just webhook reads. The shallow version of a POS integration reads order webhooks and writes points balances. That's useful but limited. The Habitu integration also syncs menu items, modifier groups, and branch configuration back from Foodics into the guest-facing ordering surface. When an operator updates their menu in Foodics, the change propagates to the branded app. This is the behavior operators expect and the behavior that makes the loyalty layer trustworthy, if the menu in the app doesn't match the menu at the counter, the loyalty program is confusing at best.
Item modifiers required their own migration. Modifier groups in Foodics have a non-trivial data shape, nested option groups, required vs optional, min/max selection counts, price deltas per option. Mapping that shape cleanly into the Habitu data model required migration 0096 (modifier_groups_unique_constraint) to enforce uniqueness at the right level, and migration 0097 (widen_sort_order_to_bigint) because Foodics uses sort order values that exceeded the original integer bounds we'd spec'd. Neither migration was complicated. Both were invisible until real menu data from real operators hit the integration.
Real-time sync required its own infrastructure. Migration 0098 (realtime_for_sync_tables) added Supabase Realtime subscriptions to the sync tables so the branded app surface can push menu updates to active sessions without a full page reload. This matters more than it sounds for the in-app pickup flow: if a modifier option sells out during a busy lunch service, the app needs to reflect that before the next order, not at the next manual refresh.
What We Deferred
Full inventory sync is out of scope for v1. Foodics has an inventory management layer, stock levels, cost of goods, purchase orders. We deliberately did not integrate with it. The loyalty and ordering use case doesn't need inventory depth; it needs menu state and order events. Adding inventory sync would have doubled the integration surface and added failure modes that have nothing to do with guest growth. We'll revisit it if operators ask for it specifically, but the ask hasn't come yet.
Multi-brand Foodics accounts. Some UAE operators run multiple restaurant concepts under one Foodics account. The data isolation required for that pattern, separate loyalty pools, separate analytics, separate menus surfaced in separate apps, is non-trivial. We handle multi-location within a single brand well. Multi-brand within a single POS account is deferred.
What Comes After
Square is next for the US wedge. Square has a large installed base in the 3-to-20-location US fast-casual segment — exactly the tier we target. The integration shape will be different from Foodics: Square's payments layer (card-on-file, Apple Pay, Google Pay, saved-card wallet) is more mature and more central to the ordering experience than Foodics's. The loyalty and ordering integration will look similar at the surface; the payment infrastructure underneath will look quite different. We've already done the Square payments work. The POS integration layer is in planning.
Toast for North American expansion. Toast is the enterprise and mid-market POS for US full-service and fast-casual. It's a later priority because our US entry point is the 3-to-20-location segment where Square dominates, not the 20-to-100-location segment where Toast is strongest. When we move up-market in the US, Toast is the natural integration.
If you're an operator currently on Foodics, the integration is live. The full picture of what it enables, two-way menu sync, item-level order attribution, loyalty state written back to the POS, is covered in the Foodics integration detail post. If you're on Square, or planning a US launch, the timeline for Square POS integration is the right thing to ask about on a MENA inquiry or a direct conversation with the team.