Partner APIs
Fiscal print data
Retrieve the printable fiscal data for an order — emitter, store, buyer, document references, and country-specific fields. Use it to render a receipt or invoice from the integration side.
GET
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:
Same path, same authentication, same parameters. What changes is the response:
What v2 adds, and why it may matter to you:
- 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
Two versions, both alive
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.fiscalRepresentation— the document exactly as it was numbered, with its history. It is what makes a credit note printable: it carriescompensates(which invoice it voids, with the reason already written out) and that whole invoice inhistory. 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.
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:
graphicisnull. The QR is the DIAN catalog URL and it travels incountryData.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 VENTAinstead ofFACTURA, andVALIDACION PREVIAinstead ofEMISION NORMAL. ambientearrives translated just like in Ecuador, but mind the source code: the DIAN uses1for production and the SRI uses it for testing. Fire resolves it, which is why both readPRODUCCIONhere.authorizationProtocolcarries the CUFE, which is what identifies the document before the authority — the equivalent of Ecuador’s access key.
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 —
pdfUrlandxmlUrlmay be signed URLs that expire. - Final-consumer flag. Always check
buyer.isFinalConsumerbefore rendering buyer details. For anonymous consumers in BR,govIdNumberis"00000000000"and other buyer fields arenull. - Country-specific UI. Use
fiscal.countryCodeto dispatch to the right rendering template — DANFCE for BR NFC-e, DIAN-style for CO, SRI for EC, etc.
Related
order.completed event
The full order snapshot — much richer than fiscal-print, used for non-print integrations.
order.invoiced event
Brazil only — fires when SEFAZ authorizes; carries the same fiscal references.
Fiscal callback
The inbound endpoint your fiscal provider uses to update fiscal state.