What Is AS2? EDI's Transport Layer, Explained

AS2 is an internet protocol, standardised in RFC 4130, for sending EDI documents directly between two trading partners over HTTPS. It encrypts and digitally signs the payload using S/MIME, and confirms delivery with a signed receipt called an MDN, which is why it remains the backbone of retail and freight EDI despite being nearly two decades old.

What AS2 actually is, in one paragraph

If you've inherited an "AS2 connection" from a carrier contract and nobody on your team can explain what it guarantees, here's the short version. AS2 (Applicability Statement 2) is an HTTP-based protocol defined in RFC 4130 for transmitting EDI documents directly between trading partners over the internet, using digital certificates for encryption and signing and confirming delivery through automatic receipts called MDNs (Message Disposition Notifications). That's it. No queue, no portal, no third-party network sitting in the middle by default.

Critically, AS2 is a transport, not a document format. EDI is the data format (X12 850, 856, 810, etc.), and AS2 is one of several ways to transmit EDI files between trading partners. You can send EDI over AS2, SFTP, VAN, or other protocols. AS2 is specifically the transport layer. The EDIFACT IFTMIN or X12 204 inside the AS2 envelope looks identical whether it arrived over AS2, SFTP, or a VAN. We've covered what's inside that envelope before when we walked through building a DB Schenker IFTMIN transport order. This post is about the pipe it travels through.

AS2 vs SFTP vs VAN vs REST APIs

These four get conflated constantly because they all move EDI or JSON files between companies. They differ on who's in the middle and what proof you get back.

A VAN (Value Added Network) is a managed, store-and-forward intermediary: you drop a file, the VAN routes it to the partner's mailbox, and both sides connect to the VAN rather than to each other. AS2 is a specification that simplifies point-to-point EDI. This is important because the alternative to point-to-point is to use a Value Added Network (VAN). VANs are expensive. AS2 cuts the middleman and the per-document fees that come with it, at the cost of managing each partner connection yourself.

SFTP is the other common alternative, and the distinction that matters architecturally is the receipt. SFTP does not include an AS2-style signed MDN. That does not make SFTP unsuitable for EDI, it just means acknowledgments need to be handled differently. Common options include EDI acknowledgment files, response files, application records, audit logs, webhook-triggered notifications, or processing confirmations from the EDI system. With AS2, that non-repudiation is built into the protocol itself rather than bolted on afterwards.

AS2 provides end-to-end encryption, digital signatures, and MDNs; SFTP offers SSH encryption with secure authentication but no built-in acknowledgment mechanism; a VAN gives provider-managed encryption and delivery confirmation through tracking reports. Why does the fourth row matter for this blog specifically? Because AS2 requires both parties to support AS2, which works well in established EDI networks but can limit flexibility when partners use different systems or have lighter technical resources — and more importantly, both parties generally need to be reachable at send time. REST plus a webhook retry queue tolerates a partner being offline for an hour. Classic synchronous AS2 does not.

How an AS2 exchange actually works

The sender encrypts and signs the payload, usually an EDIFACT or X12 interchange wrapped in MIME, using the receiver's public certificate. It's POSTed over HTTPS. The receiver verifies the signature, decrypts, and returns an MDN.

Sender Receiver
|-- S/MIME encrypt + sign payload --->|
|-- HTTPS POST ---------------------->|
| |-- decrypt + verify signature
|<----------- signed MDN ------------|

Under the hood, authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts, and authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. That MDN can come back on the same connection or later. The receipt is the functional message that is sent from a receiver to a sender to acknowledge that an EDI/EC interchange has been received, and this message may be either synchronous or asynchronous; a synchronous receipt is returned to the sender over the same HTTP connection as the sender's original message.

Don't confuse the MDN with the EDI functional acknowledgment. The MDN proves the transport layer delivered bytes intact. A separate X12 997 or EDIFACT CONTRL message confirms the content was syntactically valid. The core X12 sets include 997 (functional acknowledgment that confirms receipt) as its own document, sent back through the same transport, logically distinct from the MDN. Two receipts, two layers, easy to conflate when you're debugging at 2am.

A worked example: tendering freight to DB Schenker

DB Schenker still runs core booking and tracking on UN/EDIFACT, not REST, so if your platform integrates with them at volume you need to build a valid EDIFACT IFTMIN transport order, get it through their gateway, and correctly reconcile the CONTRL, IFTMCS and IFTSTA replies that come back. Before you send a single message, you need your AS2 or OFTP2 connection details: certificates, AS2-ID or OFTP2 SSID, and the gateway endpoint for your country. That's not optional paperwork; it's the transport credential.

Here's where it bites you. Certificates expire. If nobody rotates DB Schenker's AS2 certificate before the renewal date, the connection doesn't throw a friendly error, it just stops accepting handshakes. If the receiver's gateway is temporarily unreachable, your tender is simply not delivered, and nobody tells you proactively, you find out because the carrier calls asking where the shipment is. This is exactly why AS2 is the highest-security option required by major retailers, but its complexity and 24/7 availability requirement make it the most resource-intensive to manage in-house. Multi-carrier platforms such as Cargoson, nShift, Transporeon and Alpega exist partly to absorb this: they offer direct API/EDI integrations with carriers across all transport modes, allowing you to compare rates, book shipments, and track imports and deliveries from a single platform, so the shipper isn't the one holding a certificate expiry calendar for forty carriers.

Why MDN semantics matter for idempotency design

An MDN tells you the bytes arrived. It does not tell you the receiver's downstream system processed the tender exactly once. If your AS2 client times out waiting for the MDN and retries, you may have delivered the same IFTMIN twice, and the carrier's EDI engine may or may not deduplicate on its end. That's not a hypothetical edge case, it's the normal failure mode of any synchronous acknowledgment protocol under network jitter.

This is why middleware built on top of AS2 still needs its own idempotency keys and deduplication logic downstream of the receipt, the same discipline we'd apply to any carrier webhook. The MDN is proof of transport, not a substitute for your own retry and dead-letter handling. And because an expired or misconfigured certificate fails silently rather than loudly, AS2 credentials belong in the same rotation and monitoring discipline as any other secret in the stack, not a folder someone remembers to check once a year.

FAQ

Is AS2 the same as EDI? No. EDI is the data format (X12, EDIFACT), and AS2 is one of several ways to transmit EDI files between trading partners; AS2 is specifically the transport layer.

Do I still need a VAN if I have AS2? It depends on partner count and volume. AS2 removes per-document VAN fees but puts certificate management and uptime on you; a VAN trades that fee for handling routing across many partners without you running your own AS2 server for each one.

What happens if an MDN never arrives? Treat it as an unconfirmed delivery. Depending on your client's timeout and retry configuration, you may resend, which risks duplicate processing unless your downstream system deduplicates on a message or interchange reference.

Can AS2 be replaced by a webhook or API in carrier integration? Where the carrier offers one, yes, and it generally tolerates asynchronous delivery better since both sides don't need to be online simultaneously. Many European road freight carriers, DB Schenker among them, still gate core booking through EDIFACT over AS2 rather than REST.

Is AS2 still required by carriers today, or is it legacy? Major retailers like Walmart and Target require AS2 because its non-repudiation and delivery confirmation capabilities meet their supply chain compliance standards, and the same compliance logic holds across much of European freight EDI. It's old, but it isn't going away.