AS2 Is Not Dead: What Actually Happens When You Send an EDI Document Over the Wire

If you've built your career on REST APIs, the first time a retail partner says "just send it over AS2" feels like being handed a fax machine. AS2 — Applicability Statement 2 — is a protocol from the early 2000s. It is also, quietly, still how a huge share of retail EDI actually moves. Walmart-scale supply chains don't run on webhooks. They run on AS2.

I build EDI tooling for a living, so let me walk you through what AS2 really is, what breaks in production, and why the ideas underneath it are worth stealing even if you never touch it.

It's just HTTPS with very serious envelopes

Strip away the acronyms and AS2 is: take your EDI payload (usually X12), wrap it in S/MIME — signed with your certificate, encrypted with your partner's public cert — and POST it to their AS2 endpoint over HTTPS. That's the whole transport.

The three identifiers that matter are not URLs. They're AS2 IDs — arbitrary strings like MYCOMPANY_AS2 and PARTNER_AS2 that both sides agree on out of band, usually over email or a partner portal. The certificate exchange happens the same way: you send them your public cert, they send you theirs, and somebody on each side pastes it into a configuration screen. There is no discovery, no OAuth dance, no developer portal with a "try it" button. Onboarding is a human process, and that is the first thing API developers underestimate about B2B integration: the protocol is the easy part; the ceremony around trust is the actual work.

The MDN is the original delivery receipt

Here's the part I genuinely admire. After your partner's server receives, decrypts, and verifies your document, it sends back an MDN — a Message Disposition Notification. It's a signed receipt that says, cryptographically, "I received exactly these bytes, intact, from you."

API developers reinvented this a decade later and called it webhook signature verification plus idempotency keys. AS2 had both ideas baked in from the start: the MDN proves delivery and integrity, and because it's signed by the receiver, neither side can later claim the document never arrived. In EDI disputes — did the 856 ship notice go out before the routing cutoff? — the MDN is the evidence. The 997 functional acknowledgment then confirms the content was structurally valid, which is a second, separate handshake most API folks have never had to design.

Sync MDN vs async MDN: where outages hide

You can request the MDN two ways. Synchronous: the HTTP response to your POST is the MDN. Simple, and you know immediately. Asynchronous: the partner's server accepts your POST with a plain 200 and sends the MDN later, as a separate HTTP POST back to your AS2 endpoint.

Async MDN is where production incidents live. It means your side must run a publicly reachable HTTPS endpoint with a valid certificate, your firewall must allow the partner's outbound IPs, and their MDN has to survive their network path back to you. I've seen the same failure pattern repeatedly: documents flow fine for months, then MDNs silently stop arriving because the partner rotated their sending IPs, or your cert expired at 2am, or someone tightened a firewall rule. Your system thinks everything is delivered; their system is waiting on receipts that never come. With sync MDN you feel the pain immediately. With async MDN you find out from an angry email three days later.

What breaks in practice

The failure modes of AS2 are almost never the protocol itself. They're the operational surface around it:

• Certificate expiry. Certs last a year or two, the person who installed them has changed jobs, and the renewal email went to a distribution list nobody reads. At 2am on a Sunday, every transmission starts failing signature verification.
• Unannounced cert rotation. Your partner rotates their certificate and forgets to send you the new public cert. Your encrypted payloads suddenly can't be decrypted on their end. This one generates the most confused support tickets in the industry.
• Duplicate processing. A network hiccup means your POST times out, you retry, and both copies arrive. If your receiving logic isn't idempotent on the interchange control numbers, you've just booked the same shipment twice. The protocol gives you the primitives; deduplication is still your job.
• Test vs production drift. Partners give you a test AS2 ID, test endpoint, and test cert. Production is a different set of all three. Every value must be swapped, and exactly one of them always gets missed on go-live.

None of these are exotic. They're the same class of problem as expired API credentials and misconfigured webhooks — just with certificates instead of tokens, and with onboarding measured in days instead of minutes.

Why you should care even if you never send EDI

AS2's design answers questions that modern event-driven architectures are still arguing about: How does the sender prove delivery? How does the receiver prove receipt? What counts as "the document" for dispute purposes — the bytes on the wire, or the parsed content? AS2's answer is layered and explicit: TLS for the pipe, S/MIME for the payload, MDN for receipt, 997 for content validity. Each layer has a distinct job. Most webhook systems mush all of this into "we got a 200," and then everyone acts surprised when "delivered" turns out to mean four different things.

If you're designing B2B integrations — EDI or otherwise — steal the layering. Separate transport receipt from content acknowledgment. Make receipts signed and non-repudiable. And treat partner onboarding as a first-class workflow, because in B2B the handshake is the product as much as the API is.

---

I'm Chris, founder of SignalEDI — we build AI-assisted EDI/API integration for SMBs, including AS2 connectivity without the 2am certificate archaeology. If you're staring down your first retail EDI onboarding, the protocol is the least of your worries — happy to compare notes.