Saltar al contenido principal
GET
API de partner. Este endpoint está pensado para integradores de plataforma. Los clientes estándar de Fire no tienen acceso directo — contactá a tu account manager si necesitás esta integración.
Devuelve el contexto fiscal consolidado de una orden específica — los datos que tu point-of-sale o backoffice renderizaría en un recibo/factura impreso o digital. Expone:
  • Contexto del emisor — entidad legal, gov ID, info de tienda, inscripción estatal
  • Referencias fiscales por país — chave de acesso, CUFE, clave de acceso, CAE, folio, etc., según país
  • Contexto del comprador — destinatario, con flag de anónimo/consumidor final
  • Resumen de la orden — código, status, día de negocio
Endpoint solo lectura. Sin side effects.

​
Dos versiones, las dos vivas

Mismo camino, misma autenticación, mismos parámetros. Lo que cambia es la respuesta:
La v1 no se movió ni se va a mover. Si tu integración ya la consume, no tenés que hacer nada: mismos campos y mismos valores que siempre.La v2 existe porque uno de los cambios no es aditivo — ambiente es el mismo campo con otro valor— y cambiarlo en la v1 le movería el dato bajo los pies a una caja ya integrada. No hay fecha de baja para la v1.
Consumidor KDS. fire-kds llama este endpoint con la credencial Fire resuelta como Bearer. Brasil usa v1. Ecuador y los países posteriores usan v2 (layout RIDE vía fiscalRepresentation).
Lo que la v2 agrega, y por qué puede importarte:
  • fiscalRepresentation — el documento tal como se numeró, con su histórico. Es lo que hace imprimible una nota de crédito: trae compensates (qué factura anula, con el motivo ya redactado) y esa factura completa en history. En la v1 esa información no existe.
  • Etiquetas resueltas — FACTURA, NOTA DE CREDITO RIDE, EMISION NORMAL, PRODUCCION: los códigos del ente ya traducidos, para que no lleves su tabla adentro de tu POS.
  • La fecha de emisión (issuedAt) del comprobante, que la v1 no expone.
Todo lo demás —emisor, tienda, comprador, orden— es idéntico en las dos.

​
Autenticación

​
string
requerido
Tu API key de Fire con scope orders:read. Vendor-scoped: la API key debe pertenecer al mismo vendor dueño de la tienda/orden.

​
Path parameters

​
string
requerido
Cualquiera de las tres referencias públicas de la orden:No hace falta traducir: usa el id que ya conoces.

​
Query parameters

El vendor se resuelve desde tu API key (vendor-scoped). El parámetro vendorId fue removido — si lo envías, se ignora.

​
Respuesta

​
object
Referencias fiscales comunes del documento, sin importar el país.
​
object
Referencias del documento específicas por país. La forma varía según fiscal.countryCode. Ejemplos:
  • BR: chaveAcesso (44 dígitos), serie, serialNumber
  • CO: cufe, prefijo, numeroDian
  • EC: numeroComprobante, claveAcceso (49 dígitos), numeroAutorizacion, ambiente
  • CL: folio, ted, tipoDte, trackId
  • AR: cae, fechaVtoCae, puntoVenta, numeroComprobante, tipoComprobante
  • VE: numeroControl, numeroFactura, rifEmisor
Solo en v2: los valores vienen traducidos, no en código del ente. En Ecuador el proveedor manda ambiente: "2" —así lo define el SRI— y en la v2 llega "PRODUCCION", que es lo que va impreso. En la v1 ese campo sigue trayendo "2", sin cambios. Es el mismo criterio que en la numeración fiscal: traducirlo del lado del punto de venta significaría que cada integrador lleva su copia de la tabla del ente, y el primero que la copie mal imprime “PRUEBAS” en una factura de producción.Un país sin tabla de rótulos devuelve sus valores tal cual.
​
object
Solo en v2. El documento tal como se numeró, con su histórico y las etiquetas ya resueltas. En la v1 esta clave no existe.Dentro de la v2, aparece solo cuando la venta pasó por el Fiscal Gateway. Si el comercio fiscaliza únicamente por callback —Brasil, agregadores, o el gateway desactivado— la clave no viene en la respuesta. No llega en null: no está.Es la misma forma que viaja en data.fiscalRepresentation de los eventos, así que quien aprende a leer una lee la otra.
Por qué está separado de fiscal. Responden preguntas distintas: fiscal es el documento con el veredicto del ente encima —estado, protocolo, fecha de autorización— y cambia cuando el ente contesta. Esto otro es lo que se imprimió en la caja y no cambia nunca.Cuando el SRI autoriza, fiscal.status pasa a authorized y aparecen el PDF y el XML, pero el número del comprobante sigue siendo el mismo. Son dos hechos, no dos versiones del mismo.
​
object | null
Entidad legal que emite el documento.
​
object | null
Info a nivel tienda para el header impreso.
​
object
Destinatario del documento.
​
object
Contexto mínimo de la orden para cross-reference.
Qué cambia al imprimir en Colombia, respecto del ejemplo de Ecuador de arriba:
  • graphic es null. El QR es la URL del catálogo de la DIAN y viaja en countryData.qrCode. En Ecuador el QR se deriva de la clave de acceso y por eso se entrega aparte; acá ya viene resuelto y duplicarlo daría dos copias que pueden discrepar.
  • Los rótulos son los de la DIAN: FACTURA ELECTRONICA DE VENTA en vez de FACTURA, y VALIDACION PREVIA en vez de EMISION NORMAL.
  • ambiente llega traducido igual que en Ecuador, pero ojo con el código de origen: la DIAN usa 1 para producción y el SRI para pruebas. Fire lo resuelve, y por eso acá se lee PRODUCCION en los dos.
  • authorizationProtocol lleva el CUFE, que es lo que identifica el documento ante el ente — el equivalente de la clave de acceso ecuatoriana.
Los bloques store, company y order no cambian por país, así que se omiten acá y valen los del ejemplo de Ecuador.

​
Patrones comunes

  • Fetch en tiempo de impresión. Llama este endpoint al momento de imprimir/renderizar y persiste la respuesta si necesitas artefactos durables — pdfUrl y xmlUrl pueden ser URLs firmadas que expiran.
  • Flag de consumidor final. Siempre revisa buyer.isFinalConsumer antes de renderizar detalles del comprador. Para consumidores anónimos en BR, govIdNumber es "00000000000" y otros campos del comprador son null.
  • UI específica por país. Usa fiscal.countryCode para despachar al template de renderizado correcto — DANFCE para BR NFC-e, estilo DIAN para CO, SRI para EC, etc.

​
Relacionado

Evento order.completed

El snapshot completo de la orden — mucho más rico que fiscal-print, usado para integraciones no-print.

Evento order.invoiced

Dispara cuando el ente fiscal autoriza, en cualquier país; lleva las mismas referencias fiscales.

Callback fiscal

El endpoint inbound que tu proveedor fiscal usa para actualizar el estado fiscal.