巴西经济中的每一张发票都基于 SOAP 1.2 运行。
Every invoice in Brazil's economy runs on SOAP 1.2

原始链接: https://github.com/stoix-dev/sefaz-webservices-postman

此存储库提供了一套完整且具备文档说明的 Postman 合集,用于集成巴西税务单据的网络服务(NF-e、NFC-e、CT-e 和 MDF-e)。其目标是集中处理通常需要查阅大量 SEFAZ 手册的技术规范(SOAP 1.2 信封、URL 及特殊要求)。 **重点功能:** * **实用性:** 提供带有可配置变量(`{{url}}`、`cnpj`、`cUF` 等)的现成请求。 * **验证:** CT-e 和 MDF-e 的分发服务已在生产环境中完成验证。 * **配置:** 包含使用 A1 证书(`.pfx`)及调整 Postman 信任存储(trust store)的基本说明。 * **局限性:** Postman 无法执行 XML 签名(授权和事件处理所必需);需要签名的请求必须通过外部代码进行处理。 * **维护:** 项目通过脚本(`gen_inventario.py`)实现自动化,欢迎通过 Pull Request 贡献代码,并采用 MIT 许可协议。 非常适合寻求简化与 SEFAZ 和国家环境(Ambiente Nacional)API 的查询、状态及分发流程,并希望减少技术资料搜寻成本的开发者。

巴西 2 万亿美元的经济规模依赖于一个庞大且强制性的、基于 SOAP 1.2 的电子发票系统。接入该基础设施的难度众所周知,开发人员需要查阅超过 1000 页碎片化且前后不一致的文档。常见的技术陷阱包括针对相似文档的不兼容 XML 信封,以及会导致标准 SOAP 实现被拒收的非标准报文头要求。 为简化这一流程,Stoix 的开发人员创建了一个全面且经过验证的 Postman 合集,映射了所有 29 个政府 Web 服务。通过自动化 mTLS 设置并提供可直接发送的信封,该资源将数小时的手动调试过程缩减为即插即用的解决方案。该项目是开源的,并由 Python 清单生成,便于社区对各州的 URL 映射进行贡献。 尽管 Hacker News 上的讨论反思了使用 SOAP 等陈旧协议带来的技术挫败感,但舆论普遍认为,正是 SOAP 的严谨性和模式验证(schema validation),使其成为支撑如此庞大且关键的政府业务的核心支柱。
相关文章

原文

Coleção Postman completa e documentada dos webservices dos documentos fiscais eletrônicos brasileiros: NF-e (55), NFC-e (65), CT-e (57) e MDF-e (58).

Arquivo: postman/SEFAZ-Webservices-Catalogo.postman_collection.json (29 itens em 5 pastas: uma por modelo + referência de eventos.)

Integrar com a SEFAZ exige garimpar manuais (MOC NF-e/NFC-e 4.00, CT-e 4.00, MDF-e 3.00b, NT 2015.002) e portais de autorizadores para descobrir URL, envelope SOAP e peculiaridades de cada serviço. Esta coleção entrega isso pronto: cada request com envelope SOAP 1.2 montado e variáveis {{}}.

Os dois serviços de distribuição DFe (CT-e e MDF-e) foram validados contra a SEFAZ em produção em 12/09/2026 (cStat 137) e estão marcados com [OK testado].

  1. Import > postman/SEFAZ-Webservices-Catalogo.postman_collection.json.
  2. Certificado (Settings > Certificates > Add Certificate): adicione seu e-CNPJ A1 (.pfx + senha) por host. Para as distribuições: www1.cte.fazenda.gov.br, mdfe.svrs.rs.gov.br, mdfe-homologacao.svrs.rs.gov.br.
  3. Settings > General: desligue "SSL certificate verification" (as ACs da ICP-Brasil não estão no trust store do Postman).
  4. Em cada request, copie a URL (homolog ou prod, da descrição) para a variável {{url}}, ajuste cnpj, cUF, tpAmb etc, e dispare.
  • [cadeado] no nome: o XML de dados exige assinatura XMLDSig (autorização, eventos, inutilização). O Postman não assina XML; para esses serviços use um assinador ou código próprio. Consultas, status e distribuição não assinam.
  • [OK testado]: validado contra a SEFAZ (cStat 137).
  • Todos SOAP 1.2: o action viaja no Content-Type, não em header SOAPAction.

Diferenças que pegam (aprendidas no teste real)

  • CT-e distribuição (Ambiente Nacional): distDFeInt COM cUFAutor, wrapper cteDistDFeInteresse > cteDadosMsg, sem cabecMsg.
  • MDF-e distribuição (SVRS): distDFeInt SEM cUFAutor (o cUF vai no mdfeCabecMsg do header), mdfeDadosMsg direto no Body. Só tem distNSU e consNSU (não tem consChNSU).
  • NF-e distribuição (AN): igual ao CT-e (com cUFAutor), versão 1.01.
  • CT-e 4.00: autorização é só síncrona (SincV4/OSV4/GTVeV4); lote assíncrono e inutilização não existem no rol nacional.
  • MDF-e 3.00: autorização síncrona com área de dados em GZip+base64.
  • NFC-e: exige CSC + QR Code (infNFeSupl); sem SVC (contingência offline tpEmis=9); UFs AM/GO/MS/MT/PR/RS/SP têm ambiente próprio.
  • URLs default do SVRS (atende a maioria das UFs) + Ambiente Nacional para as distribuições. Não cobre as 27 UFs uma a uma; para autorizador próprio (ex. NFC-e SP), trocar a URL na variável.
  • Eventos estão como pasta de referência (códigos de tpEvento); são enviados pelo RecepcaoEvento do respectivo modelo.

Fonte de verdade: gen_inventario.py gera inventario.json; build_collection.py monta o .json do Postman. Para propor mudança, edite o gen_inventario.py, rode os dois e abra um PR.

Mantido pela Stoix. Licença MIT.

联系我们 contact @ memedata.com