Why compare approaches
Most merchants do not choose between “use Fire spark” and “use nothing.” They choose between how to connect their operation to sales channels — one aggregator at a time, many vendors stitched together, a custom platform built in-house, or a single omnichannel layer. This page is for commercial, marketing, and product leaders evaluating that decision. It focuses on outcomes: reach, consistency, speed to launch, and visibility across channels.Fire spark in one sentence
Fire spark sits between your POS / RMS and every sales channel — owned (app, web, kiosk, call center) and aggregators (Uber Eats, Rappi, PedidosYa) — syncing menus outward, routing orders back, and applying cross-channel intelligence from one place.Approaches merchants typically consider
Fire spark vs. a single-aggregator API
If you have integrated with Uber Eats Marketplace or a similar partner API, the primitives are familiar: authenticate, map stores, sync menus, receive orders via webhook, inject into POS. The difference is scope. A single-aggregator API optimizes one channel. Fire spark generalizes the same model across your full channel mix.
When a single-aggregator API is enough: You only sell on one marketplace, have no owned ordering channels, and do not need a unified menu or analytics layer.
When Fire spark fits better: You operate or plan to operate on multiple surfaces and want one operational connection instead of repeating the same integration work per partner.
Fire spark vs. a fragmented multi-vendor stack
Many merchants end up here by default: Uber Eats middleware from vendor A, Rappi from vendor B, a white-label app from vendor C, web ordering from vendor D. Each piece works in isolation, but nothing shares a single source of truth.
When fragmentation is tolerable: Low channel count, rarely changing menus, and no priority on direct ordering or unified reporting.
When Fire spark fits better: Brand consistency matters, menus change often, and commercial teams need one picture of performance across the network.
Fire spark vs. building in-house
Large brands sometimes build internal middleware: menu transformers, webhook routers, channel-specific adapters, and operational tooling. Full control, but ongoing engineering and operational cost.
When in-house makes sense: Unique requirements no platform can meet, a mature platform team, and omnichannel as a core differentiator you want to own completely.
When Fire spark fits better: You want omnichannel outcomes without standing up a permanent integration platform team.
Capability comparison at a glance
✓ = supported natively or as a primary use case. Partial = possible but
inconsistent or requires extra tooling. — = not a typical strength of that
approach.
What stays the same with Fire spark
Fire spark does not replace your POS, RMS, or kitchen workflow. Your team keeps fulfilling orders where they already do. Fire spark changes how menus and orders move between that stack and the channels customers use — not how you run the restaurant.Choosing the right path
Next steps
Overview
What Fire spark is and what you can build
Quickstart
Connect your operation and activate channels
Integrations API
POS/RMS sync and order injection
Storefront API
Owned app, web, and kiosk channels