Skip to main content
The fiscal callback does one thing: it writes the tax authority’s verdict on the order. Events are not built from the callback — they are built from what the order stores. So the question “what does my consumer receive?” always has the same answer: fiscal.authority, with the shape described here. If you have not read it yet, How fiscal works in Fire explains the two acts and the two blocks this page assumes.

​
What happens, step by step

  1. Your provider posts the fiscal callback. Fire validates it and answers 202 Accepted. A 202 means queued, not processed, and never means an event was sent.
  2. A background worker stores the verdict on the order, usually within a couple of seconds.
  3. Depending on eventType, Fire emits an event to your Integration Flows — or not.

​
Which event fires

An event is emitted only when the callback actually changed the document. A resend of a state already applied (idempotent), a callback that would move the document backwards (regression) or one that matches no document (notFound) is still answered with 202, and emits nothing.
order.cancelled does not come from the callback. It fires when the order is cancelled in Fire, before the authority is asked. The authority’s confirmation arrives later as a cancelled callback, which produces order.reversed.

​
Where each field of the callback lands

Everything below lands in orders.fiscal.authority, and from there in the events. Three rules explain the table:
  • document becomes countryData. Fire keeps no list of each country’s keys: anything in document reaches countryData untouched. A new identifier your authority starts requiring travels without any change on Fire’s side.
  • provider and metadata keep the numbering’s names. On the numbering side the provider also sends provider and metadata, and Fire exposes them as providerIdentity and providerMetadata. The callback does the same, so both blocks of the order read alike. providerIdentity.reference is what you quote to the provider to find the operation in their records.
  • Empty means null, not absent. A callback without provider or metadata (or with {}) stores providerIdentity: null and providerMetadata: null.

​
Where it appears in each event

The field-by-field reference of that block is in the fiscal block.

​
The path without a callback: Brazil (PlugNotas)

In Brazil there is no fiscal callback: Fire learns the SEFAZ verdict directly from PlugNotas. The block your consumer receives has the same shape, with these differences:

​
One order, end to end

The same Brazilian order through the fiscal callback, trimmed to the fiscal parts.
1

Callback: authorized

2

Fire answers 202, then stores the verdict

3

order.invoiced carries it

4

The order is cancelled in Fire

order.cancelled fires immediately with data.cancellation.fiscal = { "status": "authorized", "authority": { … } } — the invoice as it was. Nothing has been asked to the authority yet.
5

Callback: cancelled, then order.reversed

The provider sends eventType: "cancelled" with its own eventId (reusing the authorization’s returns 409). Fire emits order.reversed with authority.documentType: "CREDIT_NOTE", cancelledAt set, both documents in history, and compensates pointing at the invoice.

​
What does not happen

  • No event for rejected, denied or error. They are stored; your consumer only sees them in lastKnown.fiscal.status of a later event.
  • A 202 is not an event. Poll the outcome endpoint if you need to know the callback was processed.
  • The callback does not change fiscalRepresentation. What was printed at the till stays as it was.
  • There is no guard by provider. An order holds a single document. When the order already has a document, an authorized whose eventId does not match it ends in notFound and changes nothing; when the order has no document, the authorized creates it. An eventId that Fire never emitted for that order is rejected with 400 before the 202. A cancelled resolves the order’s most recent document and updates it, whichever provider issued it — PlugNotas included.