Skip to main content
POST
​
string
required
Bearer token obtained from POST /login. Format: Bearer <accessToken>.
​
string
required
Your Fire API key.
​
string
required
Must be integration. Identifies the request as coming from an external integration.
​
string
required
Account identifier the request belongs to.
​
string
required
Unique order identifier from your system.
​
string
required
Order origin. Examples: App, Kiosco.
​
string
Client platform. Examples: Android, iOS, Web.
​
object
required
Sales channel details. Use uid values from publication webhook payloads (for example channel.updated) or from your channel setup in the Fire dashboard (Aggregator integrations).
​
object
required
Fulfillment service details. Use uid values from the services array in those channel payloads or from the same sources as channel.
​
object
Device details. null for channels without a physical device.
​
object
Result of Request fiscal document, copied as is. Optional: if you did not fiscalize before injecting, omit it — Fire handles fiscalization on its own.Fire takes the receipt data for the order from here and ignores the rest. The document’s status before the tax authority is Fire’s job: documentStatus is ignored if sent.
​
object
Operator or cashier who processed the order. null for self-service channels.
​
string
required
Shipping method selected by the customer. Values: delivery, pickup.
​
boolean
Whether the customer is accumulating loyalty points on this order.
​
boolean
Whether the customer is redeeming loyalty points on this order.
​
boolean
Whether discounts are applied on this order.
​
string
General comment from the customer for the entire order.
​
object
required
Customer information.
​
object
required
Store where the order is placed.
​
object
required
Order contents.
​
object
required
Shipping details depending on selectedShippingMethod.
​
object
required
Payment breakdown.
​
object
Loyalty and coupon information.
​
object
Extra order-level metadata (e.g. kiosk IP address).

​
Amounts and price bands

Fire does not scale or recalculate prices. Send amounts in the final currency unit (for example "8.99" for USD 8.99, not cents). Your POS or aggregator must send values already calculated.
Product lines, payments.totals[], payments.shippingCost[], and payments.discounts[] all use the same price band keys: currencyCode, subtotalWithoutTaxes, discountPercentage, discountsValue, subtotalIncludeDiscounts, taxesPercentage, taxValue, total.

​
Shipping and discounts

​
Product-line discounts

Apply discounts on order.products[n].price.unitPrice and totalPrice (same numbers when quantity is 1). Example: 10% off a 15.00 base with 12% VAT → discountsValue 1.50, subtotalIncludeDiscounts 13.50, taxValue 1.62, line total 15.12.

​
payments.shippingCost[]

Delivery or shipping fees as one or more price-band rows. In the examples below, shipping tax is calculated on the shipping base the same way as on products.

​
payments.discounts[]

Order-level discounts (promos, coupons) as price-band rows. Use this when the discount is not already fully reflected in each product’s discountsValue and the cost is absorbed by the store. Product discounts and payments.discounts[] can be combined; reconcile against paymentMethods[].totalBill.

​
payments.totals[]

Roll-up of the product portion of the order. When reconciling: products (totals) + shipping − order discounts ≈ amount paid.
Fire does not reject the request if paymentMethods[].totalBill differs slightly from the sum of bands—still send consistent values from your source system.

​
Combo discounts

When a combo product has a container price of 0 (i.e. type: "COMBO" with subtotalWithoutTaxes: 0), the combo discount must not be placed on the container line. Assigning discountsValue to a zero-base produces negative totals, which Fire rejects. Instead, distribute the full discount amount across the selectedModifiers that make up the combo.

​
Rules

​
Distribution algorithm

Adjust rounding on the last modifier so that SUM(discount_i) === D exactly. If proportional distribution would leave any modifier with net_i < 0, cap that modifier’s discount at its base price (discount_i = base_i, net = 0) and redistribute the remainder among the others.

​
Example — BRL 17.94 discount on a combo (base BRL 89.68)

The following shows the incorrect pattern (discount placed on the container) and the correct pattern (discount spread across modifiers).
Incorrect — discount on zero-base COMBO (totals go negative)
Correct — COMBO container at zero, discount on modifiers
The full discount breakdown for this example (all 7 modifiers): payments.totals[0].subtotalWithoutTaxes = 89.68, subtotalIncludeDiscounts = 71.74 ✓

​
Aggregator discounts

When an aggregator platform (iFood, Rappi, UberEats, etc.) applies a promotional discount to the customer, the aggregator reimburses the store for that amount — the store always receives the full price. This means the discount is not a deduction from the store’s revenue and must not appear in payments.discounts[]. Model it instead as an extra entry in payments.paymentMethods[]:

​
Required fields on the AGGREGATOR_DISCOUNT entry

​
Balance rule

The sum of all paymentMethods[].totalBill entries — including the AGGREGATOR_DISCOUNT entry — must equal the gross order total:
payments.discounts[] stays empty.

​
Example reconciliations

Calculation notes:
  • Simple delivery: 8.99 + 1.73 = 10.72.
  • Line discount: 10% off 15.00 → tax on 13.50 → product 15.12; shipping 3.50 + 12% VAT = 3.92; 15.12 + 3.92 = 19.04.
  • Multi-product + promo: burgers 25.80 + drink 5.00 = 30.80; + shipping 3.50 = 34.30; − promo 2.00 = 32.30 paid.
  • Aggregator discount: products 29.80 + packaging 0.99 + shipping 8.90 = 39.69 gross; customer pays 38.69 (CREDIT) + aggregator reimburses 1.00 (AGGREGATOR_DISCOUNT) = 39.69 ✓. payments.discounts is empty.