Every invoice in Brazil's economy runs on SOAP 1.2

It isn't that bad, at least XML is machine friendly, supports schema validation, and does comments, contrary to its replacements that had to rediscover why such features matter.

As for performance, that was also rediscovered why none of them are great, thus gRPC rediscovering CORBA, COM and Sun RPC.

When we rolled out an ERP in our Brazil subsidiary the whole internal consulting team immediately agreed to leave our brains untouched by this complexity and hire a local consultant team as help. And the local consultant team in turn immediately suggested useing a middleware provider.

Similar in Georgia https://eservices.rs.ge/app/Downloads

XML/SOAP based protocol was created with modern at the time .Net technologies, but nobody really cared about interoperability, so it screams "old .Net" now.

This sounds similar to Ukrainian cash registers. Every retail operation goes through a cash register API on the tax agency side (because who would not love to keep some cash off the books, right), but there it is RESP+JSON and a cottage industry of services running it for you. It would not even be that hard is it wasn't sneaking the whole PKI into it.

Every SAML IdP (and there are still a lot) using the Artifact binding runs on SOAP 1.2, so what.

Oh gosh. I could only imagine how many apps in chain crafts and parses soap envelopes with adhoc code with mandatory info loss.

seems like a great idea, as long as it's well maintained etc

Brazil runs the largest mandatory e-invoicing system on Earth. Every invoice, every truckload, every retail receipt in a $2T economy passes through government SOAP 1.2 webservices. In 2026.

Want to integrate? The documentation is four PDF manuals totaling over 1,000 pages, spread across different portals, with critical details that are simply not written anywhere. Two examples we paid for in hours of debugging: the freight document (CT-e) and the manifest (MDF-e) implement the same distribution spec with incompatible envelopes (one wraps the payload and requires an author state code, the other rejects that field and wants the state code in the SOAP header). And the SOAP action must travel inside the Content-Type header; send a SOAPAction header like every SOAP tutorial on the internet tells you to, and the server refuses you without explaining why.

So we mapped all 29 webservices across the 4 document models into one Postman collection: ready-to-fire envelopes, per-host mTLS certificate setup documented, and the distribution services validated against the production government endpoints, not just written from the manuals.

Where you can make it better: Brazil has 27 states and several run their own authorizer URLs (Sao Paulo's retail invoices, for one). We cover the shared authorizer plus the national environment; state-specific URL mappings are the top open contribution. The collection is generated from a Python inventory file, so a PR is a 5-line diff, not JSON surgery.

Docs in Portuguese (the devs suffering with this are Brazilian), but I'll answer anything here in English.