NF-e events JSON — field reference

Reference document — Field-by-field dictionary of the metadata object returned by the inbound NF-e events endpoint. The same object, compressed (Gzip+Base64), is the content of the json field when json=true.

Endpoint: GET /api/integration/dfe/nfe/inbound/eventos · OpenAPI reference: NF-e Public API.

Conventions used in this documentCopy Anchor Link

• eventDatePart is the event's date partition (derived from chNFe), not an instant — it is returned as an ISO datetime string ("2026-01-01T00:00:00"). The other dates (dhEvento, dhRegEvento, createdAt, updatedAt) are returned as epoch milliseconds UTC.
• issuerType is always "INBOUND" in this listing — the same data model also stores OUTBOUND events (transmitted by MI itself), but they do not appear here.
• detEvento (the full signed event detail) is not serialized in this object — obtain it via xml=true.
• emailDest and username vary by event origin. In DF-e Distribution events (authored by third parties, e.g., cancellation, correction letter) both are always null — the Distribution does not carry a recipient email nor the user responsible for the transmission, so the key is absent from the actual JSON. In the four recipient manifestations (acknowledgment, confirmation, operation unknown, operation not performed), the event is transmitted by MI itself on behalf of the client: username is populated with the user who transmitted it, and emailDest comes back empty ("", not null) when SEFAZ does not return it — in that case the key appears in the JSON with an empty string.

1. FieldsCopy Anchor Link

2. Event types (tpEvento)Copy Anchor Link

The recipient manifestation events — authored by a company of your tenant about a received invoice:

In addition to these, events received via DF-e Distribution authored by third parties appear (e.g., cancellation 110111, correction letter 110110, etc.) when the tenant is a counterparty. There is no closed catalog in the backend — the parser accepts any tpEvento that DF-e Distribution delivers; the list of valid types is defined by SEFAZ, not by MI. The endpoint does not filter by tpEvento.

3. Multiplicity per companyCopy Anchor Link

The same SEFAZ event may appear more than once when several companies of the tenant are parties to the affected NF-e — each company receives its own copy of the event, with a distinct companyId and the same chNFe/eventId.

4. ExampleCopy Anchor Link

Example of a recipient manifestation (Acknowledgment of the Operation, tpEvento 210210) — which is why username is populated and emailDest comes as an empty string. In a DF-e Distribution event (e.g., a third-party cancellation), both keys would be absent from the JSON.

{
  "eventDatePart": "2026-01-01T00:00:00",
  "id": "0198c0de-0000-7000-8000-000000000003",
  "customerId": "0198c0de-0000-7000-8000-000000000001",
  "companyId": "0198c0de-0000-7000-8000-000000000002",
  "chNFe": "35260111111111111111550010000000011000000015",
  "issuerType": "INBOUND",
  "eventId": "ID2102103526011111111111111155001000000001100000001501",
  "cOrgao": "91",
  "tpAmb": 2,
  "cnpjCpfAutor": "11111111111111",
  "tpEvento": 210210,
  "dhEvento": 1768469400000,
  "nSeqEvento": 1,
  "cStat": 135,
  "xMotivo": "Evento registrado e vinculado a NF-e",
  "xEvento": "Ciencia da Operacao",
  "cnpjCpfDest": "22222222222222",
  "emailDest": "",
  "dhRegEvento": 1768471200000,
  "nProt": 135260000000002,
  "createdAt": 1768478400000,
  "updatedAt": 1768478700000,
  "username": "mde-service"
}