Skip to main content
Emitir uma nota pela API da Spedy é uma operação assíncrona: a resposta 2xx do POST que cria a nota confirma apenas que a solicitação foi aceita para processamento — não que a nota foi autorizada pela SEFAZ ou pela prefeitura. Entre a criação e a autorização, a nota passa por uma sequência de estados, e o tempo entre um estado e outro varia de segundos a, em contingência, horas ou dias. Há dois caminhos de entrada, que diferem em quando a nota é enfileirada:
  • POST direto na nota (/v1/product-invoices, /v1/consumer-invoices, /v1/service-invoices): a nota já é enfileirada para emissão no próprio POST — não existe um passo de emissão separado.
  • Via venda (POST /v1/orders): a emissão segue o autoIssueMode da venda — pode ser imediata ou ficar aguardando (created) até um gatilho (ex.: afterPayment). Veja Fluxo de emissão.
Saber em qual estado a nota está — e o que fazer em cada um — é o que permite ao seu sistema decidir quando liberar a mercadoria, emitir o DANFE/DANFSE ou notificar o cliente, em vez de assumir que “a chamada respondeu 200, então a nota está pronta”.

Estados e transições

O campo status (InvoiceStatus) de uma nota — NF-e, NFC-e ou NFS-e — segue a máquina de estados abaixo:
authorized, rejected, denied e canceled são estados terminais para aquela numeração — uma nota rejeitada ou denegada não “vira” autorizada depois; você corrige o problema e emite uma nova nota. A exceção é inContingent, que é sempre transitório: assim que a autoridade volta a operar e o lote é reprocessado, a nota é reclassificada como authorized ou rejected.

O que cada status significa

InvoiceStatus não é InvoiceProcessingStatus. São dois campos diferentes e é fácil confundir os dois:
  • InvoiceStatus (status) é o estado fiscal da nota — os valores da tabela acima (created, authorized, rejected etc.).
  • InvoiceProcessingStatus é o estado interno de processamento de um evento na fila: processing (aguardando execução), success (o evento foi executado) ou failed (falha interna de infraestrutura ao processar o evento).
success em InvoiceProcessingStatus não significa nota autorizada — significa que a Spedy conseguiu executar aquele passo do fluxo (enviar o lote, receber a resposta da SEFAZ, atualizar o status). Uma nota rejeitada também tem InvoiceProcessingStatus igual a success, porque o processamento funcionou normalmente; só o resultado fiscal foi negativo. Para saber se a nota foi autorizada, olhe sempre o InvoiceStatus — nunca o InvoiceProcessingStatus.

Como acompanhar as transições

Não faça polling apertado esperando a nota “ficar pronta” logo após criá-la. Use um dos dois mecanismos abaixo.

Webhooks (recomendado)

A forma mais eficiente de saber que o status mudou é configurar um webhook: a Spedy notifica seu sistema a cada transição relevante (recebida, autorizada, rejeitada, cancelada etc.), sem que você precise consultar a API. Veja Visão geral de webhooks e Eventos e payload para o formato de cada evento.

Obter a nota fiscal (GET por ID)

Se você não usa webhooks, obtenha a nota (GET .../{id}) para ler o status atual guardado pela Spedy — essa leitura não aciona a SEFAZ.

Reconciliar com a SEFAZ (check-status)

O endpoint check-status consulta a nota diretamente na SEFAZ/prefeitura e reconcilia o resultado no seu registro. Use-o apenas para destravar ou reconciliar uma nota cujo status no Spedy pode estar desatualizado — por exemplo, uma nota marcada como rejected que na verdade consta autorizada na SEFAZ, ou um acompanhamento automático que esgotou as tentativas. Enquanto a nota ainda está enqueued (não enviada à autoridade), esse endpoint responde erro — ele não serve para “furar a fila” e forçar uma emissão imediata.