NF-e eventos JSON — referência de campos

Documento de referência — Dicionário campo a campo do objeto metadata retornado pelo endpoint de eventos NF-e inbound. O mesmo objeto, comprimido (Gzip+Base64), é o conteúdo do campo json quando json=true.

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

Convenções deste documentoCopiar link da seção

• eventDatePart é a partição de data do evento (derivada de chNFe), não um instante — sai como string ISO datetime ("2026-01-01T00:00:00"). As demais datas (dhEvento, dhRegEvento, createdAt, updatedAt) saem como epoch milliseconds UTC.
• issuerType é sempre "INBOUND" nesta listagem — o mesmo modelo de dados também guarda eventos OUTBOUND (transmitidos pelo próprio MI), mas eles não aparecem aqui.
• detEvento (o detalhe assinado completo do evento) não é serializado neste objeto — obtenha-o via xml=true.
• emailDest e username variam por origem do evento. Nos eventos de Distribuição DF-e (autorados por terceiros, ex.: cancelamento, carta de correção) ambos são sempre null — a Distribuição não carrega e-mail de destinatário nem usuário responsável pela transmissão, então a chave fica ausente do JSON real. Já nas quatro manifestações do destinatário (ciência, confirmação, desconhecimento, operação não realizada), o evento é transmitido pelo próprio MI em nome do cliente: username vem preenchido com o usuário que transmitiu, e emailDest volta vazio ("", não null) quando a SEFAZ não o devolve — nesse caso a chave aparece no JSON com string vazia.

1. CamposCopiar link da seção

2. Tipos de evento (tpEvento)Copiar link da seção

Os eventos de manifestação do destinatário — autorados por uma empresa do seu tenant sobre uma nota recebida:

Além destes, aparecem eventos recebidos via Distribuição DF-e autorados por terceiros (ex.: cancelamento 110111, carta de correção 110110, etc.) quando o tenant é contraparte. Não há catálogo fechado no backend — o parser aceita qualquer tpEvento que a Distribuição DF-e entregue; a lista de tipos válidos é definida pela SEFAZ, não pelo MI. O endpoint não filtra por tpEvento.

3. Multiplicidade por empresaCopiar link da seção

Um mesmo evento SEFAZ pode aparecer mais de uma vez quando várias empresas do tenant são partes da NF-e afetada — cada empresa recebe sua própria cópia do evento, com companyId distinto e o mesmo chNFe/eventId.

4. ExemploCopiar link da seção

Exemplo de uma manifestação do destinatário (Ciência da Operação, tpEvento 210210) — por isso username vem preenchido e emailDest vem como string vazia. Num evento de Distribuição DF-e (ex.: cancelamento de terceiro), ambas as chaves estariam ausentes do 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"
}