Skip to main content

Fire

Fire is the restaurant management OS and the source of truth for orders, stores, menus, products, and sales channels. Any change made in Fire is the authoritative version that may produce events your system can react to.

Your system

Your system is the integration you build. It connects to Fire by:
  • Receiving events from Fire through one or more Integration Flows, and acting on them (publishing to aggregators, syncing a billing system or ERP, triggering internal workflows, etc.).
  • Injecting orders into Fire when needed.
The integration interface is the same regardless of what your system does with the data.

Sales channels

Sales channels are the aggregators (iFood, Keeta, 99, Rappi, etc.) and direct channels (POS, kiosk, app, web) configured inside Fire for a given store. Each channel has a unique ID inside Fire. If your system needs to inject orders or map them to upstream systems, it must fetch the channel list once and keep it cached.

Events

Fire emits four event types in production today:
EventWhen it fires
order.completedAn injected order is fully received and paid (status=COMPLETED, paymentStatus=SUCCEEDED).
order.cancelledAn injected order is cancelled from the backoffice or via an external adapter.
order.invoicedBrazil only — SEFAZ authorizes the order’s fiscal document via your fiscal provider.
order.reversedBrazil only — SEFAZ confirms cancellation of a previously authorized fiscal document.
Each event payload is self-contained — it includes the full V4 order snapshot (and, for fiscal events, the fiscal block) so your system can act without additional API calls. See Events overview for the envelope and delivery model.

Integration Flows

An Integration Flow is how your system subscribes to events. You configure flows in the Fire dashboard under Settings → Integration Flows, scoping each flow to your account, vendor, and (optionally) specific stores. A flow is a graph of nodes — typically a trigger followed by an HTTP node that POSTs the event body to your URL — but it can also transform, branch, log, or call internal Fire services before reaching out. A flow’s HTTP node owns the request: method, URL, headers, authentication, and the body template that defines what your endpoint receives. Fire does not impose a fixed envelope — most teams start from the canonical example template the dashboard ships with.

Orders

Orders are injected into Fire via the REST API. Each order payload must include the Fire sales channel ID so that Fire can associate it with the correct channel and store configuration. Once injected and paid, the order produces an order.completed event; cancellations produce order.cancelled.

Webhook endpoint

The HTTPS URL on your side that receives requests from a flow’s HTTP node. Unlike a global webhook endpoint, you can have a different URL per flow if you want to fan out events to different services (e.g. one URL for fiscal events, another for order events). You configure each URL in the dashboard when setting up the flow.