AS2 Protocol Explained: EDI for Carrier Connections

What is AS2?

AS2, short for Applicability Statement 2, is the internet protocol most carriers and shippers use to send EDI documents like transport orders and invoices directly and securely between two computer systems, without a third-party network in between. AS2 is an HTTP-based protocol for securely, inexpensively, and quickly transmitting messages, particularly EDI messages, over the internet, ensuring data integrity, encryption, and authentication by using digital certificates and encryption standards.

If you've been told by DB Schenker, DSV or DHL Freight that you need "an AS2 connection" before they'll accept your electronic transport orders, this is what they mean. It's not a file format. It's the delivery mechanism, the truck, not the cargo.

AS2 vs. EDI vs. API: where the confusion starts

People use "EDI" and "AS2" interchangeably, and that's the first mistake worth fixing. AS2 is a secure communication protocol that transmits EDI documents over the internet, while EDI defines the structured format of the business documents, like purchase orders and invoices. An IFTMIN transport order or an INVOIC invoice is a document standard. AS2 is one of several ways to move that document from your system to your carrier's.

Second confusion: AS2 vs. the old Value-Added Network (VAN) model. Before AS2 existed, EDI ran mostly over dial-up modems and paid VANs that acted as a mailbox in the middle. AS2's most common application is for EDI transactions, replacing the older and more expensive VAN technology. With AS2, your server talks straight to the carrier's server over HTTPS. No mailbox, no VAN subscription fee, no waiting for a polling cycle. Third confusion, and the one that matters most on this blog: AS2 vs. modern REST/JSON carrier APIs. These are different generations of technology solving a similar problem in different ways. AS2 is a fixed-file, batch-oriented, certificate-heavy exchange built for EDIFACT or X12 payloads. A REST API is request/response, uses JSON, and typically authenticates with OAuth tokens rather than digital certificates. Most European shippers today run both at once: AS2 for the DB Schenkers and DSVs of the world that still mandate EDIFACT, and REST APIs for carriers who've modernized their tracking, label or rate endpoints. That mixed estate is exactly why carrier connectivity has gotten harder to maintain in-house, not easier.

How AS2 actually works, step by step

In practice, an AS2 exchange is a four-step handshake between two systems that already trust each other's certificates. Your ERP or TMS builds the EDI document, encrypts it, and pushes it over HTTPS; the receiver decrypts it, verifies it, and sends back a receipt.

1. Your system (ERP, TMS, or EDI gateway) generates the EDI message, for example an IFTMIN transport order, and encrypts it using the carrier's public certificate so only they can open it.
2. Your system signs the message with your own private certificate, so the carrier can prove it really came from you, then transmits it over HTTP/S. AS2 creates an "envelope" that embeds secure transmission via the internet using a combination of digital certificates and encryption.
3. The carrier's AS2 gateway decrypts the payload, verifies your signature, and processes the transport order or invoice into their own system.
4. The carrier sends back a Message Disposition Notification (MDN). When using AS2, the sender will always get an acknowledgement notifying them if their partner has successfully received the message or not.

Before any of that works, both sides need AS2-capable software or a gateway, a valid digital certificate exchanged with the partner, a static AS2 identifier and endpoint URL, and firewall rules that allow inbound connections on the agreed port. This setup work is exactly why AS2 onboarding with a new carrier can take weeks rather than hours, and why it's one of the first things to break when a carrier renews its certificate and forgets to tell you.

A worked example: sending a transport order over AS2

Take a European retailer running its TMS to book a pallet shipment with DB Schenker. The TMS generates an IFTMIN message. IFTMIN is the EDI for booking shipments, structured per DB Schenker's own EDIFACT specification. That message gets encrypted and pushed via AS2 to Schenker's inbound gateway. Schenker's system replies with an MDN confirming receipt, and separately, IFTMCS acts as a receipt and confirmation that the EDI is received. As the shipment moves, Schenker pushes status updates back through the same AS2 channel using IFTSTA, which carries observations that have happened along the route. Later, the invoice arrives the same way, often as an INVOIC message, through the identical certificate-secured connection. Nothing here involves a browser, a portal login, or a human. It's machine-to-machine, running on a schedule, invisible until it breaks. This is also where AS2 adoption shows its retail roots. Walmart was the first major retailer to require its suppliers to use the AS2 protocol instead of relying on dial-up modems, and Amazon, Target, Lowe's, Bed Bath & Beyond and thousands of others followed suit. Freight carriers inherited the same infrastructure because many of them serve retail supply chains directly, and AS2 was already sitting on the shelf as the accepted way to move EDIFACT documents securely. Few shippers build this plumbing from scratch anymore. Most either run their own AS2 gateway and EDI mapping layer in-house, hand the whole thing to an EDI integration platform, or use a TMS that bundles carrier connectivity into the product itself, as Cargoson does, so the AS2 certificates, IFTMIN mapping and MDN handling sit behind a normal user interface rather than a server room. Others route through Transporeon's partnership with nShift, or bring in a system integrator like Coneksion to build and maintain the connection on their behalf.

Why AS2 hasn't gone away, even with carrier APIs on the rise

AS2 persists because ripping it out is expensive and nobody wants to be the one who breaks a working invoice feed. Its ability to support multiple data formats and avoid EDI VAN fees makes it a cost-effective choice for industries like retail, logistics, and manufacturing. But that cost-effectiveness comes with its own tax: AS2 adoption comes with challenges, such as managing trading partner connections, maintaining certificates, and configuring firewalls.

For a shipper with 50 or 200 carrier connections, that means 50 or 200 sets of certificates expiring on different schedules, 50 or 200 firewall rules to keep straight, and a support queue every time one carrier renews its endpoint URL without warning. Meanwhile a growing number of carriers are pushing new integrations toward REST APIs instead of AS2, which doesn't remove the old connections, it just adds a second technology stack to maintain in parallel. That's the real state of carrier connectivity for most mid-to-large European shippers right now: not a clean migration from AS2 to API, but a permanent mixed environment.

Frequently asked questions

Is AS2 the same thing as EDI?
No. EDI is the document standard, like EDIFACT IFTMIN or INVOIC. AS2 is one of the protocols used to transmit those documents securely over the internet.

Do I still need a VAN if I'm using AS2?
No. AS2 was designed as a direct, point-to-point alternative to VANs, which is precisely why it caught on so fast after Walmart mandated it for suppliers.

What is an AS2 certificate, and do I need a separate one per carrier?
It's a digital certificate used to encrypt and sign your messages so only the intended receiver can read them and verify who sent them. In practice, most shippers exchange a distinct certificate pair with each individual trading partner, which is why certificate management becomes a real operational burden once you're connected to dozens of carriers.

Is AS2 secure enough for freight invoices and customs-relevant data?
Yes. AS2 leverages encryption, digital signatures, and certificates to ensure data confidentiality, authenticity, and integrity while enabling real-time acknowledgments, which is why it remains acceptable for financial and compliance-sensitive documents.

Are carriers replacing AS2 with REST APIs?
Some are building parallel API options for newer integrations, particularly for real-time tracking and rating, but AS2 remains entrenched for transport orders and invoicing wherever EDIFACT is already the agreed format between shipper and carrier.

Can a TMS handle AS2 for me instead of building it in-house?
Yes, several TMS platforms and connectivity layers manage the AS2 gateway, certificates and EDIFACT mapping behind the scenes, so your team interacts with a normal booking screen rather than a raw EDI feed.