> ## Documentation Index
> Fetch the complete documentation index at: https://firespark.cloud/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Comparison
> How Fire spark compares to single-aggregator APIs, fragmented integrations, and in-house omnichannel builds.
## 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
| Approach | Summary |
| --------------------------------- | ---------------------------------------------------------------------------------------------- |
| **Single-aggregator API** | Integrate directly with one marketplace (for example Uber Eats). Strong for that channel only. |
| **Fragmented multi-vendor stack** | Separate tools or integrations per aggregator, plus another stack for app and web. |
| **In-house omnichannel platform** | Custom middleware, menu sync, and order routing built and maintained by your team. |
| **Fire spark** | One hub: POS/RMS in, all channels out, intelligence and routing in the middle. |
## Fire spark vs. a single-aggregator API
If you have integrated with [Uber Eats Marketplace](https://developer.uber.com/docs/eats/guides/getting-started) 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.
| | Single-aggregator API | Fire spark |
| ---------------------------------- | ------------------------------------ | ----------------------------------------------------------------------------- |
| Channels covered | One marketplace | Owned channels + multiple aggregators |
| Menu workflow | Push or sync to that partner | Sync from POS/RMS; compose menus per channel, store, fulfillment, or schedule |
| Order routing | That channel → your POS | Any channel → Fire spark → your POS/RMS |
| Reporting | Siloed to that partner | Consolidated across channels |
| Intelligence | Rules specific to that partner | Cross-channel rules and menu composition on one platform |
| Integration effort per new channel | New project, new vendor relationship | Extend existing merchant setup |
**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**.
| | Fragmented stack | Fire spark |
| ------------------------------------ | --------------------------------------------- | ---------------------------------------------------------------------- |
| Menu consistency | Manual reconciliation; drift between channels | Operational sync from POS; composed menus per selling context |
| Time to update pricing or 86 an item | Touch each system separately | Update once in the POS; rules decide how each menu variant reflects it |
| Order operations | Multiple dashboards and alert paths | Orders from all channels into the same stack |
| Commercial planning | Hard to compare channel performance | Cross-channel analytics and monitoring |
| Vendor relationships | Multiply contracts and support lines | One platform layer; channels as configuration |
| Owned vs aggregator channels | Often different products entirely | Same merchant model for app, web, and marketplaces |
**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**.
| | In-house build | Fire spark |
| -------------------------------- | ------------------------------------------- | ------------------------------------------------------- |
| Upfront build | Large custom project | Connect POS/RMS and configure channels |
| Maintenance | Every aggregator API change is your problem | Platform handles channel connectivity and sync patterns |
| Intelligence and experimentation | Build analytics, A/B, and rules yourself | Cross-channel intelligence as part of the layer |
| Time to add a channel | Engineering sprint per surface | Activate and configure in the hub |
| Team focus | Platform team maintains pipes | Product and growth focus on customer experience |
| Risk | Key-person and bus-factor on custom code | Managed APIs and documented integration model |
**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
| Capability | Single-aggregator API | Fragmented stack | In-house build | Fire spark |
| ------------------------ | :-------------------: | :--------------: | :------------: | :--------: |
| Multiple aggregators | — | Partial | ✓ | ✓ |
| Owned app / web / kiosk | — | Partial | ✓ | ✓ |
| Menu sync from POS/RMS | Partial | Partial | ✓ | ✓ |
| Unified order routing | Partial | — | ✓ | ✓ |
| Cross-channel analytics | — | — | Custom | ✓ |
| Menu experimentation | — | — | Custom | ✓ |
| Low engineering overhead | ✓ | — | — | ✓ |
| Fast new-channel launch | — | — | — | ✓ |
✓ = 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.
```
POS / RMS → Fire spark → Channels
(sync, intelligence, routing)
```
## Choosing the right path
| Your situation | Suggested direction |
| ---------------------------------------------- | ------------------------------------------------ |
| One aggregator, no owned channels | Single-aggregator API may suffice |
| Growing channel mix, menu drift is a problem | Fire spark or equivalent omnichannel hub |
| Many vendors, no unified reporting | Consolidate on a single layer |
| Heavy engineering team, omnichannel as core IP | Evaluate in-house vs managed layer on total cost |
## Next steps
What Fire spark is and what you can build
Connect your operation and activate channels
POS/RMS sync and order injection
Owned app, web, and kiosk channels