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 /v1/nfe/emissoes (ide.modelo="65")
→
Motor calcula tributos, resolve o CSC, monta o QR Code, assina e transmite pra SEFAZ
→
200 OK · resultado final (mesma chamada)
💡
Síncrono, mesmo padrão de NF-e/CT-e/MDF-e/NFS-e. A própria chamada
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
POST https://areacliente.centralfiscal.com.br/v1/nfe/emissoes
⚠️
Cobertura de QR Code hoje: só RS. A URL do QR Code e a URL de consulta
por chave variam por UF -- só temos a fórmula e as URLs oficiais confirmadas pra RS.
Emitir NFC-e (modelo 65) pra outra UF falha explicitamente
(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.
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.
⚠️
Nem todos fazem sentido pra venda de balcão. A CentralFiscal não
bloqueia nenhum deles no seu lado -- quem decide se um evento se aplica ao modelo 65 é a
SEFAZ, na hora de processar. Na prática:
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.
Se a SEFAZ rejeitar por regra de negócio do modelo, o erro vem no mesmo formato de
sempre -- ver Rejeições SEFAZ.
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 em detalhes e extrair o elemento qrCode pra imprimir/exibir no PDV.
Se precisar cancelar, ver POST /v1/nfe/cancelamentos acima.
Reconsultar mais tarde, se precisar: GET /v1/nfe/emissoes/{transmissao_id}.