Portais Oficiais — NF-e / NFC-e
Atualizado em 24/08/2026Links diretos para os recursos oficiais do Portal Nacional da Nota Fiscal Eletrônica (NF-e) e Nota Fiscal de Consumidor Eletrônica (NFC-e), em produção e homologação.
Relação dos serviços Web (WebServices)
Lista oficial dos serviços web disponíveis (autorização, consulta, status, inutilização, entre outros).
Sem variação por ambiente
— os mesmos links em produção e homologação, o seletor acima não se aplica a elesO que cada web service de NF-e faz
- Autorização
- Recebe o lote de notas assinadas. Pode responder na hora (modo síncrono, uma nota) ou devolver um recibo para consulta posterior (assíncrono).
- Retorno da autorização
- Consulta o resultado de um lote enviado em modo assíncrono, a partir do recibo. É onde chega o protocolo de autorização ou a rejeição.
- Consulta protocolo
- Situação atual de uma nota a partir da chave de acesso: autorizada, cancelada, denegada. Útil para recuperar o protocolo de uma nota cujo retorno se perdeu.
- Status do serviço
- Informa se o autorizador está operando. É a consulta que embasa a decisão de entrar em contingência.
- Inutilização
- Declara uma faixa de numeração que não será usada (por exemplo, números pulados por falha do sistema), para que o salto não pareça omissão de nota.
- Recepção de evento
- Cancelamento, carta de correção, manifestação do destinatário e demais eventos vinculados a uma nota já autorizada.
- Distribuição de DF-e
- Fica no Ambiente Nacional, não na UF: é por onde se baixam os documentos em que o seu CNPJ é parte interessada, como notas emitidas contra você.
Produção x homologação, e o que costuma dar errado na conexão
Cada serviço tem dois endereços, e o seletor de ambiente acima alterna entre eles. O ambiente também vai dentro do XML, no campo tpAmb (1 = produção, 2 = homologação), e os dois precisam concordar: um XML com tpAmb=2 enviado ao endereço de produção é rejeitado. Documentos autorizados em homologação não têm valor fiscal. Na NF-e, o nome do destinatário em homologação precisa ser substituído pelo texto padrão que indica ambiente de testes.
A comunicação é SOAP sobre HTTPS com autenticação mútua: além de validar o certificado do servidor, o autorizador exige que o cliente apresente no próprio handshake TLS um certificado ICP-Brasil (A1 ou A3) do contribuinte. Quando a conexão falha antes de qualquer resposta SOAP, a causa costuma estar em um destes pontos, e não no XML:
- O runtime da sua aplicação não confia na cadeia de certificados da Sefaz. Várias cadeias usam autoridades certificadoras brasileiras que não vêm instaladas por padrão em Java, .NET ou em imagens Linux mínimas.
- O certificado do cliente não foi anexado à conexão, ou foi anexado sem a chave privada, o que é comum ao carregar um A1 (.pfx) com a senha errada ou sem a flag de exportação.
- Certificado vencido, ou emitido para um CNPJ diferente do emitente. A raiz do CNPJ precisa bater com a do emitente do documento.
O certificado usado no TLS é o mesmo que assina o XML, mas são dois usos diferentes. Uma conexão funcionando não garante que a assinatura esteja correta. Veja o artigo sobre assinatura digital de XML.