Emitir NFC-e POST
NFC-e (modelo 65, venda a consumidor final) usa o mesmo endpoint de
NF-e -- é o campo ide.modelo: "65" que muda o
documento, não uma rota separada. Esta página documenta o fluxo completo com foco nas
diferenças reais; o que não é mencionado aqui funciona igual à NF-e.
Quando utilizar
Sempre que seu PDV/ERP precisar emitir uma NFC-e de venda de balcão a consumidor final, identificado ou não. Cada chamada gera exatamente um documento -- para venda B2B com destinatário identificado por CNPJ, normalmente é NF-e (modelo 55) que se aplica, ver NF-e.
Pré-requisitos além dos de NF-e
- Tudo que NF-e já exige (contribuinte cadastrado, certificado A1).
-
CSC (Código de Segurança do Contribuinte) cadastrado -- sem ele a
emissão falha antes de tentar montar o XML, porque não dá pra gerar o QR Code
obrigatório do NFC-e. Hoje o cadastro do CSC é só pela Área do Cliente (tela de sessão
logada) -- não existe endpoint público
/v1/...pra isso ainda.
Fluxo da operação
POST já calcula os tributos, resolve o CSC, monta o QR Code, assina e
transmite pra SEFAZ -- a resposta já vem com status final
(AUTHORIZED/REJECTED/ERROR/PROCESSING),
não um "recebido, consulte depois".
Endpoint
NFCe ainda nao suportada para esta UF/ambiente) em vez de gerar um QR
Code com URL genérica ou inventada.
Campos que mudam pra NFC-e
| Campo | Diferença |
|---|---|
ide.modelo | Envie "65" -- se omitido, o padrão é "55" (NF-e). |
destinatario | Opcional -- pode omitir inteiro em venda a consumidor final não identificado. Se informar, precisa vir completo (mesma validação da NF-e). |
ide.presenca_comprador | Importante informar -- o padrão da API é NAO_PRESENCIAL_OUTROS (indPres=9), errado pra venda de balcão. Use PRESENCIAL pra PDV comum. Ver Enums pros demais valores. |
ide.consumidor_final | Normalmente CONSUMIDOR_FINAL pra NFC-e (o padrão da API é NORMAL, que é o certo pra NF-e B2B). |
Exemplo mínimo
Venda de balcão, um item com ICMS já retido por ST anteriormente (CST 60) -- comum em PDV de varejo -- veja o código ao lado.
Resposta de sucesso
200 OK -- mesmo formato de resposta da NF-e, mas o detalhes.xml
gerado já vem com o grupo infNFeSupl (QR Code + URL de consulta por chave) --
é isso que sua tela de PDV ou impressora fiscal precisa pra montar o DANFCe. O QR Code em
si não vem como campo separado no JSON -- extraia o elemento qrCode do XML
baixável pela URL em detalhes.
danfe_pdf_base64 continua no
leiaute de sempre (sem IBS/CBS) -- nenhuma mudança visual acontece automaticamente no
campo que você já consome hoje. Durante esse período, a resposta também traz
danfe_pdf_base64_reforma (mesma regra de null em falha), já
no leiaute novo (DANFE Simplificado com a caixa "Total do IBS/CBS/IS"), pra quem quiser
testar/se adaptar antes do corte. A partir de 01/12/2026,
danfe_pdf_base64 passa a trazer só o leiaute novo, e
danfe_pdf_base64_reforma some da resposta.
Resposta de erro
Exemplo real: emitir pra uma UF ainda sem cobertura de QR Code -- 400 Bad Request.
Catálogo completo de erros: Tratamento de Erros.
Notificação assíncrona
Não existe webhook genérico hoje -- e como a chamada já é síncrona (a resposta já traz o
resultado final), normalmente você não precisa de nada além do próprio POST.
Cancelamento
Usa o mesmo POST /v1/nfe/cancelamentos da NF-e (mesmos campos:
chave_acesso/protocolo/justificativa com pelo menos
15 caracteres). Mesmo padrão síncrono da emissão: a resposta já vem com o resultado final
do evento de cancelamento na SEFAZ. Exemplo de request/resposta:
ver na página de NF-e (é o mesmo endpoint,
documentar duas vezes só divergiria com o tempo).
Outros eventos (mesmos endpoints da NF-e)
Carta de Correção, Ator Interessado, os eventos RTC e a Manifestação do Destinatário também usam exatamente os mesmos endpoints documentados pra NF-e -- não existe rota nem motor separado pra NFC-e, a chave de acesso de 44 dígitos já identifica o modelo (65) sozinha. Tecnicamente qualquer um deles aceita uma chave de NFC-e.
- Carta de Correção e Manifestação do Destinatário normalmente são rejeitados pela SEFAZ pra NFC-e -- venda de balcão em geral não tem destinatário identificado, e a regra de negócio do modelo 65 não prevê esses dois fluxos. Envie só se você já confirmou que a UF em questão aceita.
- Ator Interessado e os eventos RTC são cenários de B2B/importação/apuração -- raro fazer sentido numa venda a consumidor final, mas nada nosso impede o envio.
O que ainda não existe
- Cadastro de CSC via API pública -- só pelo portal, sessão logada.
- Cobertura de QR Code fora do RS.
Próximos passos
- Baixar o XML (com
infNFeSupl) usando a URL emdetalhese extrair o elementoqrCodepra imprimir/exibir no PDV. - Se precisar cancelar, ver
POST /v1/nfe/cancelamentosacima. - Reconsultar mais tarde, se precisar:
GET /v1/nfe/emissoes/{transmissao_id}.