Skip to main content
This section is for fiscal providers, not for points of sale. If you are integrating a POS or a kiosk that consumes FIRE’s numbering, what you want is the fiscal integration guide.

​
The two integrations, which are not the same

There are two distinct and opposite connections around fiscal numbering:
The point of sale asks FIRE for numbers to print. FIRE asks the fiscal provider for them, and the provider is the one that talks to each country’s tax authority. This section defines the second arrow: what we send a provider and what we expect back.

​
It is a canonical contract

It does not describe what one particular provider does: it is the requirement. Anyone integrating with the Fiscal Gateway implements this same endpoint, with this same shape. It does not change per provider or per country. That has a consequence worth understanding before reading the detail:
The contract uses FIRE’s vocabulary, not the tax authority’s. No codes from the SRI (Ecuador’s tax authority), the DIAN (Colombia’s) or the SEFAZ travel across it. No identifiers from the provider’s catalog travel either.The provider translates into whatever each country requires — that is precisely its job. A contract that spoke one authority’s language would stop working for the next one.
That is why the request carries operation: "INVOICE" and not documentTypeCode: "01"; store.code and not establishmentCode; device.externalId and not pointOfEmissionCode. The field names are the same ones FIRE’s events already use (order.completed, order.invoiced). Anyone already consuming events learns no new vocabulary.

​
What has to be implemented

One endpoint per country, synchronous:
A single integration: one baseUrl, one credential. The routes that exist are the countries you serve, so a new country is added without touching the ones already working. It receives a sale and returns the fiscal identifiers needed to print it. It sits on the critical path of the sale —the register is waiting— so the target latency budget is under 3 seconds.
This endpoint produces the fiscal representation: the numbers to print. Submission to the tax authority and its authorization happen afterwards, on the provider’s side, and the outcome arrives via the callback. They are two distinct lifecycles and the contract does not mix them.

​
Where to go next

Endpoint contract

Authentication, request, response, errors and idempotency. The full requirement.

What reaches the integrator

How what you return ends up travelling in the order’s events.

Real examples

Requests and responses captured from a working integration.