Skip to main content
GET
Returns all orders of the account + vendor bound to your API key. Supports pagination, a rich set of filters, and field projection (choose which fields each order returns). To list the orders of a single store, use List store orders.

​
Authentication

​
string
required
Your Fire API key with the orders:read scope. The key must be vendor-scoped (account + vendor binding) — keys without a vendorId are rejected with 403.

​
Query parameters

The account and vendor are derived from your API key (vendor-scoped) — you do not send them as query params.
​
string
Comma-separated list of fields to return (projection). See Field projection. Omit to return every field. An unknown field yields 400.
​
string
OPEN, COMPLETED, FORCE_CLOSED, CANCELLED.
​
string
PENDING, SUCCEEDED, FAILED.
​
string
Exact business day, YYYY-MM-DD.
​
string
Range start, YYYY-MM-DD.
​
string
Range end, YYYY-MM-DD.
​
string
default:"business_day"
business_day or created_at.
​
string
default:"+00:00"
Timezone offset (+HH:MM) used with dateFilterMode=created_at.
​
string
Channel code (APP, KIOSK, …).
​
string
Fulfillment service code.
​
string
Payment method code (e.g. CASH).
​
string
Partial match on order code.
​
string
Exact UUID, or partial match on external order id / order code.
​
integer
default:"1"
Page number (1-based).
​
integer
default:"20"
Page size (1–100).

​
Request

​
Field projection

The consumer decides which fields each order returns, similar to MongoDB projection or the Elasticsearch _source parameter.
  • No fields → every field is returned.
  • fields=id,orderCode,totals → only those fields.
  • A field outside the catalog → 400 with the list of allowed fields.
Available fields: id, orderCode, orderExternal, accountId, vendorId, storeId, stationId, anonymousCustomerId, customerId, billingId, status, paymentStatus, channel, businessDayDate, createdAt, updatedAt, completedAt, deletedAt, store, customer, billing, fulfillment, orderLines, totals, paymentMethods, settlement, payments, metadata, kitchen, aggregator, fiscal.
channel is the order’s catalog id (orders.catalog_id), exposed under the channel name.
The JSONB snapshots (totals, orderLines, paymentMethods, store, customer, fulfillment, metadata, fiscal) are returned in Fire’s internal persistence format (for example, totals amounts are scaled ×10000).

​
Payment progress: settlement and payments

When an order is charged after it opens, status and paymentStatus only tell you whether it was charged. They say OPEN and PENDING both for an order nobody has tried to charge and for one whose card was declined twice — and those are very different situations for whoever is watching. Read settlement to know whether and how it was charged, and payments to know with what. The charge is all or nothing (see Confirm payment), so paidSoFar is either 0 or the full total — never something in between.
While an order is open, paymentMethods is what the POS declared when the order was created — not what has been charged. It is overwritten with the real tenders only when the order settles. Summing it to compute progress gives the wrong number. Use settlement.paidSoFar.
order.settlement (shape)
status is one of pending, declined, settled. paidSoFar and total use the same ×10000 scale as totals — above, 35.90 collected in two tenders, after one earlier decline. tenderCount counts approved tenders only; declined ones are in declinedCount. amountMismatch is always false: a charge that does not add up to the total is rejected outright, so a settled order always matches. The field is kept for compatibility. origin tells you where paidSoFar comes from, and the two are not equally backed: ledger means the tenders were counted one by one as they arrived; intake means the order was created already declaring itself paid and Fire took its word. settlement is null on orders created before this field existed. declaredMethods is what the order said it would be paid with, when it was created. Compare it with paymentMethods to see whether the customer paid with what they announced: an order created as IFOOD and charged with CREDIT shows declaredMethods: ["IFOOD"] and paymentMethods with CREDIT. It is the only place the declared method survives, because settling overwrites paymentMethods with the real tenders. Only the codes travel — the declared amounts come from the POS in units ("35.9") while paidSoFar is ×10000, and mixing both scales in one object invites mistakes.

​
payments — the tenders one by one

The pieces of the collection, oldest first. Declined tenders are included: settlement.declinedCount says how many there were, payments says which ones and why.
An order that never went through Confirm payment — a pre-paid one, for example — returns payments: [], never null. completedAt is the moment the collection closed the order, and is null while it stays open.

​
The fiscal block by country

When an order has a fiscal document, the fiscal field carries its current state. Its metadata sub-object holds the common fields plus only the identifiers for fiscal.countryCode — the other countries’ identifiers are not included. Read fiscal.countryCode to know which identifiers to expect.
order.fiscal (shape)
status tells you where the order stands fiscally. Group it by what you can do about it:
awaiting_payment and not_issued describe the order’s fiscal state, not a document’s — there is no document in either case. They exist because processing used to mean two incompatible things: “an issuance is in flight” and “this order has not reached invoicing yet”. They appear on orders that are open and unpaid, so they are most common alongside deferred payment. They are not sent in order events; there lastKnown.fiscal reports null.
The metadata common fields (all countries): docType, docSubtype, providerDocId, pdfUrl, xmlUrl, emittedAt, cancelledAt, totalAmount, taxAmount, currencyCode. On top of those, metadata carries only the identifiers of the document’s own country — the other countries’ identifiers are not included.
totalAmount and taxAmount are NOT scaled. They arrive exactly as the fiscal provider sent them in the callback: 95000 is 95,000 COP, not 9.50.It is the exception on this page: totals, paidSoFar and the payment amounts travel ×10,000, because they are values FIRE computes and stores. The ones in metadata belong to the authority’s document and are stored as is.
metadata — CO (DIAN)

​
The fiscal block carries the document’s full journey

fiscal mirrors the pattern of kitchen: the top level is the current state, and fiscal.history[] lists every stop the fiscal document made, in chronological order.
Statuses: pending, processing, contingency, fiscal_graphic, error, authorized, rejected, denied, cancelling, cancelled. See Fiscal callback for what each one means. Reading the top level keeps working exactly as before — history is additive. Use it when you need the authorization data of a document that was later cancelled: it lives in the authorized entry.

​
Response

​
object[]
Array of orders, each projected according to fields.
​
object

List store orders

Same listing, scoped to a single store.

Get order

Read a single order by id.