Skip to main content
As duas APIs emitem de forma assíncrona. O POST salva a nota, põe a emissão na fila e retorna 201 com a situação pendente. Cada tipo de nota tem um destino fiscal e uma forma de acompanhar o resultado, descritos abaixo.

​
NF-e (Nota de Produto)

​
Emissão assíncrona

POST /notas salva a nota e põe a autorização na fila da SEFAZ. A resposta é 201 Created com situacao: "pendente". O uuid e a chave_acesso são gerados na criação e já vêm definitivos nessa resposta. Há duas formas de acompanhar o resultado:

Polling

Consulte GET /notas/{uuid} até a situacao mudar.

Webhooks

Assine os eventos nfe_*. Veja Webhooks.
Depois de nfe_solicitacao_autorizacao, o próximo webhook já traz o resultado final: nfe_autorizada, nfe_rejeitada ou nfe_denegada. A Invo não envia evento para o estado em_processamento.

​
Estados (situacao)

​
Cancelamento

DELETE /notas/{uuid}/cancel pede o cancelamento (evento 110111) de uma nota autorizada. A justificativa é obrigatória e tem de 15 a 255 caracteres. O processamento é assíncrono: a API retorna 202, e o resultado chega pelo webhook (nfe_cancelamento_autorizado ou nfe_cancelamento_rejeitado) ou pelo polling.
A janela consultiva de cancelamento é de 24 horas depois da autorização. Uma nota que não está autorizada não pode ser cancelada e recebe 422.

​
Inutilização síncrona

POST /inutilizacoes inutiliza uma faixa de numeração. É a única operação que chama a SEFAZ durante a requisição. A chamada SOAP é curta e o resultado vem na resposta: 200 quando a faixa foi inutilizada, 422 quando a SEFAZ rejeitou o pedido.

​
Documentos

Depois da autorização, baixe os documentos fiscais pelas rotas autenticadas:
  • GET /notas/{uuid}/xml: XML autorizado (nfeProc), em application/xml.
  • GET /notas/{uuid}/danfe: DANFE em application/pdf. A Invo gera o PDF no primeiro acesso.

​
NFS-e (Nota de Serviço)

​
Emissão assíncrona por RPS

POST /notas salva a nota e gera um RPS (Recibo Provisório de Serviços). A Invo põe o RPS na fila e o envia em lote à prefeitura. A resposta é 201 Created com rps.situacao: "pendente" e nfse.situacao: "pendente". O id já vem definitivo nessa resposta.
A resposta tem duas máquinas de estado. O RPS é o recibo que a Invo envia à prefeitura. A NFS-e é a nota que a prefeitura emite a partir dele. No uso normal, acompanhe nfse.situacao. Consulte rps.situacao para entender uma falha de envio.
O acompanhamento é por polling:

Polling

Consulte GET /notas/{id} até nfse.situacao virar emitida, com nfse.numero e codigo_verificacao, ou até o RPS falhar com rps.situacao: "processado_com_erro".
Ao contrário da NF-e, a API NFS-e não envia webhooks. Acompanhe por polling. Os e-mails de notificação da conta continuam a ser enviados.

​
Estados da NFS-e (nfse.situacao)

​
Estados do RPS (rps.situacao)

Estes estados ajudam a diagnosticar o envio do lote à prefeitura:

​
Cancelamento

DELETE /notas/{id}/cancel pede o cancelamento de uma nota emitida. O motivo_cancelamento é obrigatório. O processamento é assíncrono: a API retorna 202, e nfse.situacao passa a cancelada quando a prefeitura confirma. Acompanhe por polling. Uma nota com nfse.situacao diferente de "emitida" recebe 422.
A NFS-e não tem inutilização de faixa nem download de XML e DANFE. O comprovante da nota é o codigo_verificacao, que você confere no portal da prefeitura.