> ## 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. # Comparación > Cómo se compara Fire spark con APIs de un solo agregador, integraciones fragmentadas y builds omnicanal in-house. ## Por qué comparar enfoques La mayoría de los comercios no elige entre “usar Fire spark” y “no usar nada”. Elige **cómo** conectar su operación a los canales de venta — un agregador a la vez, muchos vendors armados a mano, una plataforma custom in-house, o una sola capa omnicanal. Esta página es para líderes comerciales, de marketing y de producto que evalúan esa decisión. El foco está en resultados: alcance, consistencia, velocidad de lanzamiento y visibilidad entre canales. ## Fire spark en una frase Fire spark queda entre tu **POS / RMS** y **cada canal de venta** — propios (app, web, kiosco, call center) y agregadores (Uber Eats, Rappi, PedidosYa) — sincronizando menús hacia afuera, enrutando pedidos de vuelta y aplicando **intelligence cross-channel** desde un solo lugar. ## Enfoques que suelen evaluar los comercios | Enfoque | Resumen | | - | - | | **API de un solo agregador** | Integración directa con un marketplace (por ejemplo Uber Eats). Fuerte solo para ese canal. | | **Stack multi-vendor fragmentado** | Herramientas o integraciones separadas por agregador, más otro stack para app y web. | | **Plataforma omnicanal in-house** | Middleware, sync de menús y routing de pedidos construidos y mantenidos por tu equipo. | | **Fire spark** | Un hub: POS/RMS entra, todos los canales salen, intelligence y routing en el medio. | ## Fire spark vs. API de un solo agregador Si integraste con [Uber Eats Marketplace](https://developer.uber.com/docs/eats/guides/getting-started) o una API similar, los bloques suenan familiares: autenticar, mapear tiendas, sincronizar menús, recibir pedidos vía webhook, inyectar al POS. La diferencia es el **alcance**. Una API de un solo agregador optimiza un canal. Fire spark generaliza el mismo modelo en todo tu mix de canales. | | API de un solo agregador | Fire spark | | - | - | - | | Canales cubiertos | Un marketplace | Canales propios + varios agregadores | | Flujo de menú | Push o sync a ese partner | Sync desde POS/RMS; composición por canal, tienda, fulfillment u horario | | Routing de pedidos | Ese canal → tu POS | Cualquier canal → Fire spark → tu POS/RMS | | Reporting | Aislado a ese partner | Consolidado entre canales | | Intelligence | Reglas de ese partner | Reglas cross-channel y composición de menús en una plataforma | | Esfuerzo por canal nuevo | Proyecto nuevo, relación nueva | Extender la configuración del comercio | **Cuándo alcanza una API de un solo agregador:** Solo vendes en un marketplace, no tienes canales propios de pedido y no necesitas menú ni analítica unificados. **Cuándo encaja mejor Fire spark:** Operas o planeas operar en varias superficies y quieres una conexión operativa en lugar de repetir la misma integración por partner. ## Fire spark vs. stack multi-vendor fragmentado Muchos comercios llegan aquí por defecto: middleware de Uber Eats del vendor A, Rappi del B, app white-label del C, web del D. Cada pieza funciona sola, pero **nada comparte una fuente de verdad**. | | Stack fragmentado | Fire spark | | - | - | - | | Consistencia de menú | Reconciliación manual; drift entre canales | Sync operativo desde POS; menús compuestos por contexto de venta | | Tiempo para actualizar precio o 86 un ítem | Tocar cada sistema por separado | Actualizar una vez en el POS; las reglas definen cómo se refleja en cada variante | | Operación de pedidos | Varios dashboards y alertas | Pedidos de todos los canales al mismo stack | | Planificación comercial | Difícil comparar performance por canal | Analítica y monitoreo cross-channel | | Relaciones con vendors | Multiplicar contratos y líneas de soporte | Una capa de plataforma; canales como configuración | | Canales propios vs agregadores | A menudo productos distintos | Mismo modelo de comercio para app, web y marketplaces | **Cuándo se tolera la fragmentación:** Pocos canales, menús que casi no cambian y poca prioridad en pedido directo o reporting unificado. **Cuándo encaja mejor Fire spark:** La consistencia de marca importa, los menús cambian seguido y los equipos comerciales necesitan una sola foto de performance en la red. ## Fire spark vs. construir in-house Marcas grandes a veces construyen middleware interno: transformadores de menú, routers de webhooks, adapters por canal y tooling operativo. Control total, pero **costo continuo de ingeniería y operación**. | | Build in-house | Fire spark | | - | - | - | | Construcción inicial | Proyecto custom grande | Conectar POS/RMS y configurar canales | | Mantenimiento | Cada cambio de API de agregador es tuyo | La plataforma cubre conectividad y patrones de sync | | Intelligence y experimentación | Construyes analítica, A/B y reglas vos | Intelligence cross-channel como parte de la capa | | Tiempo para sumar un canal | Sprint de ingeniería por superficie | Activar y configurar en el hub | | Foco del equipo | Equipo de plataforma mantiene tuberías | Producto y growth en la experiencia del cliente | | Riesgo | Dependencia de personas y código propio | APIs gestionadas y modelo de integración documentado | **Cuándo tiene sentido in-house:** Requisitos únicos que ninguna plataforma cubre, equipo de plataforma maduro y omnicanal como diferenciador core que querés poseer por completo. **Cuándo encaja mejor Fire spark:** Querés resultados omnicanal sin montar un equipo permanente de integraciones. ## Comparación de capacidades | Capacidad | API un agregador | Stack fragmentado | Build in-house | Fire spark | | - | :-: | :-: | :-: | :-: | | Varios agregadores | — | Parcial | ✓ | ✓ | | App / web / kiosco propios | — | Parcial | ✓ | ✓ | | Sync de menú desde POS/RMS | Parcial | Parcial | ✓ | ✓ | | Routing unificado de pedidos | Parcial | — | ✓ | ✓ | | Analítica cross-channel | — | — | Custom | ✓ | | Experimentación de menús | — | — | Custom | ✓ | | Bajo overhead de ingeniería | ✓ | — | — | ✓ | | Lanzamiento rápido de canal nuevo | — | — | — | ✓ | > [!NOTE] > > ✓ = soportado de forma nativa o como caso de uso principal. Parcial = posible > pero inconsistente o con tooling extra. — = no es una fortaleza típica de ese > enfoque. ## Qué no cambia con Fire spark Fire spark no reemplaza tu POS, RMS ni el flujo de cocina. Tu equipo sigue cumpliendo pedidos donde ya lo hace. Fire spark cambia **cómo se mueven menús y pedidos** entre ese stack y los canales que usa el cliente — no cómo corrés el restaurante. ``` POS / RMS → Fire spark → Canales (sync, intelligence, routing) ``` ## Cómo elegir el camino | Tu situación | Dirección sugerida | | - | - | | Un agregador, sin canales propios | Puede alcanzar una API de agregador único | | Mix de canales en crecimiento, drift de menú | Fire spark o hub omnicanal equivalente | | Muchos vendors, sin reporting unificado | Consolidar en una sola capa | | Equipo de ingeniería grande, omnicanal como IP core | Evaluar in-house vs capa gestionada por costo total | ## Próximos pasos > [card] [Resumen](https://firespark.cloud/docs/es/overview.md) > > Qué es Fire spark y qué puedes construir > [card] [Inicio rápido](https://firespark.cloud/docs/es/quickstart.md) > > Conecta tu operación y activa canales > [card] [API de integraciones](https://firespark.cloud/docs/es/integrations-api/introduction.md) > > Sync POS/RMS e inyección de pedidos > [card] [API Storefront](https://firespark.cloud/docs/es/storefront-api/introduction.md) > > Canales propios: app, web y kiosco This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.