Skip to main content
GET
Partner API. This endpoint is intended for platform integrators. Standard Fire customers do not have direct access — contact your account manager if you need this integration.
Returns the consolidated fiscal context for a specific order — the data your point-of-sale or backoffice would render on a printed/digital receipt. It exposes:
  • Emitter context — legal entity, gov ID, store info, state registration
  • Country-specific fiscal references — chave de acesso, CUFE, clave de acceso, CAE, folio, etc., per country
  • Buyer context — recipient, with anonymous/final-consumer flagging
  • Order summary — code, status, business day
This endpoint is read-only. Side effect-free.

​
Two versions, both alive

Same path, same authentication, same parameters. What changes is the response:
v1 has not moved and it is not going to. If your integration already consumes it, you do not have to do anything: same fields and same values as always.v2 exists because one of the changes is not additive — ambiente is the same field with a different value— and changing it in v1 would move the data out from under an already integrated till. There is no sunset date for v1.
KDS consumer. fire-kds calls this endpoint with the resolved Fire credential as Bearer. Brazil uses v1. Ecuador and later countries use v2 (RIDE layout via fiscalRepresentation).
What v2 adds, and why it may matter to you:
  • fiscalRepresentation — the document exactly as it was numbered, with its history. It is what makes a credit note printable: it carries compensates (which invoice it voids, with the reason already written out) and that whole invoice in history. In v1 that information does not exist.
  • Resolved labels — FACTURA, NOTA DE CREDITO RIDE, EMISION NORMAL, PRODUCCION: the authority’s codes already translated, so you do not carry its table inside your POS.
  • The issue date (issuedAt) of the receipt, which v1 does not expose.
Everything else —emitter, store, buyer, order— is identical in both.

​
Authentication

​
string
required
Your Fire API key with the orders:read scope. Vendor-scoped: the API key must belong to the same vendor that owns the store/order.

​
Path parameters

​
string
required
Any of the order’s three public references:No translation needed: use the id you already have.

​
Query parameters

The vendor is resolved from your API key (vendor-scoped). The vendorId parameter was removed — if you send it, it is ignored.

​
Response

​
object
Common fiscal references for the document, regardless of country.
​
object
Country-specific document references. Shape varies by fiscal.countryCode. Examples:
  • BR: chaveAcesso (44 digits), serie, serialNumber
  • CO: cufe, prefijo, numeroDian
  • EC: numeroComprobante, claveAcceso (49 digits), numeroAutorizacion, ambiente
  • CL: folio, ted, tipoDte, trackId
  • AR: cae, fechaVtoCae, puntoVenta, numeroComprobante, tipoComprobante
  • VE: numeroControl, numeroFactura, rifEmisor
Only in v2: the values come translated, not as the authority’s codes. In Ecuador the provider sends ambiente: "2" —that is how the SRI defines it— and in v2 what arrives is "PRODUCCION", which is what goes on the print. In v1 that field still carries "2", unchanged. It is the same criterion as in fiscal numbering: translating it on the point-of-sale side would mean every integrator keeps its own copy of the authority’s table, and the first one to copy it wrong prints “PRUEBAS” on a production invoice.A country with no label table returns its values verbatim.
​
object
Only in v2. The document exactly as it was numbered, with its history and the labels already resolved. In v1 this key does not exist.Within v2, it only shows up when the sale went through the Fiscal Gateway. If the merchant fiscalizes solely by callback —Brazil, aggregators, or the gateway turned off— the key does not come in the response. It does not arrive as null: it is not there.It is the same shape that travels in data.fiscalRepresentation on the events, so whoever learns to read one reads the other.
Why it is separate from fiscal. They answer different questions: fiscal is the document with the authority’s verdict on top —status, protocol, authorization date— and it changes when the authority replies. This other one is what was printed at the till and it never changes.When the SRI authorizes, fiscal.status turns to authorized and the PDF and the XML show up, but the receipt’s number stays the same. They are two facts, not two versions of the same one.
​
object | null
Legal entity emitting the document.
​
object | null
Store-level info for the printed header.
​
object
Recipient of the document.
​
object
Minimal order context for cross-reference.
What changes when printing in Colombia, compared to the Ecuador example above:
  • graphic is null. The QR is the DIAN catalog URL and it travels in countryData.qrCode. In Ecuador the QR is derived from the access key and that is why it is handed over separately; here it already arrives resolved, and duplicating it would give two copies that can disagree.
  • The labels are the DIAN’s: FACTURA ELECTRONICA DE VENTA instead of FACTURA, and VALIDACION PREVIA instead of EMISION NORMAL.
  • ambiente arrives translated just like in Ecuador, but mind the source code: the DIAN uses 1 for production and the SRI uses it for testing. Fire resolves it, which is why both read PRODUCCION here.
  • authorizationProtocol carries the CUFE, which is what identifies the document before the authority — the equivalent of Ecuador’s access key.
The store, company and order blocks do not change per country, so they are omitted here and the ones from the Ecuador example apply.

​
Common patterns

  • Render-time fetch. Call this endpoint at print/render time and persist the response if you need durable artifacts — pdfUrl and xmlUrl may be signed URLs that expire.
  • Final-consumer flag. Always check buyer.isFinalConsumer before rendering buyer details. For anonymous consumers in BR, govIdNumber is "00000000000" and other buyer fields are null.
  • Country-specific UI. Use fiscal.countryCode to dispatch to the right rendering template — DANFCE for BR NFC-e, DIAN-style for CO, SRI for EC, etc.

order.completed event

The full order snapshot — much richer than fiscal-print, used for non-print integrations.

order.invoiced event

Fires when the tax authority authorizes, in any country; carries the same fiscal references.

Fiscal callback

The inbound endpoint your fiscal provider uses to update fiscal state.