AS2 (Applicability Statement 2)
AS2 (Applicability Statement 2) is a communications protocol, defined in IETF RFC 4130, for sending business documents like EDI and cXML securely over HTTP or HTTPS between trading partners. It packages the document in S/MIME to encrypt it and sign it digitally, then sends it as an HTTP POST directly to the receiving partner's server. The receiver returns a signed MDN (Message Disposition Notification) as a cryptographic receipt confirming the file arrived intact. AS2 is the connection method most large retailers and distributors require for direct, point-to-point EDI exchange, distinct from the document format (X12, EDIFACT, cXML) it carries.
How AS2 works
AS2 moves a document as an HTTP or HTTPS POST from the sender's AS2 server directly to a URL on the receiver's AS2 server — there's no intermediary network in the middle. Before sending, the sender wraps the payload (an X12 EDI file, an EDIFACT interchange, a cXML document, or any other structured data) in S/MIME, which can encrypt the contents and attach a digital signature using each party's certificate. On receipt, the recipient's AS2 server decrypts the message, verifies the signature, and sends back a Message Disposition Notification (MDN) — a signed receipt confirming the message was received and whether it was authentic and intact. A synchronous MDN returns in the same HTTP response; an asynchronous MDN arrives later as a separate POST back to the sender.
Because the signature and MDN are both cryptographically verifiable, AS2 gives both parties non-repudiation: the sender can prove the message was sent and received, and the receiver can prove it came from who it claims to. That combination — transport, encryption, signing, and receipt — is why AS2 became the default requirement for direct EDI connections with large trading partners.
Why AS2 replaced VANs and FTP for direct connections
Before AS2, most EDI ran over Value-Added Networks (VANs) — third-party mailbox services that both trading partners connected to, or over plain FTP and email, neither of which was built for encrypted, provable business document exchange. AS2 let two partners connect directly over the public internet with security and proof-of-delivery built into the protocol itself, cutting out the VAN's per-transaction fees and store-and-forward delay.
| VAN | Plain FTP / email | AS2 | |
|---|---|---|---|
| Connection | Both parties connect to a shared mailbox | Point-to-point, unencrypted by default | Point-to-point, direct |
| Encryption | Varies by VAN | None built in | S/MIME, built into the protocol |
| Delivery receipt | VAN-specific | None | Signed MDN |
| Real-time delivery | Store-and-forward | Yes, but no proof of integrity | Yes, with cryptographic proof |
| Typical cost model | Per-transaction VAN fees | Low cost, low assurance | Certificate and connection setup, no per-message VAN fee |
Many large retailers still route some partners through a VAN for volume or legacy reasons, but AS2 is the standard for partners who want a direct, auditable connection without a middleman.
Setting up an AS2 connection between trading partners
Establishing AS2 with a trading partner requires both sides to exchange a small set of connection details before the first message can flow:
- AS2 ID: a unique identifier each party assigns itself (not a domain or IP address) that identifies it as sender or receiver in every AS2 message header.
- AS2 URL: the HTTPS endpoint on the receiving party's server that accepts incoming AS2 POSTs.
- Public certificate: each party shares a certificate used to encrypt messages sent to it and to verify the signatures on messages it sends.
- MDN preference: whether receipts are synchronous or asynchronous, and whether they must be signed.
Once these are exchanged and configured in each side's AS2 software (or a hosted AS2 gateway), the two systems can send and receive without further manual intervention. Certificate expiration is the most common cause of AS2 connections breaking in production, since an expired certificate on either side will cause signature verification or decryption to fail silently until someone investigates.
AS2 vs. the documents it carries
AS2 is a transport protocol, not a document format — it's agnostic to what's inside the envelope. The same AS2 connection can carry an ASC X12 850 purchase order, an EDIFACT ORDERS message, a cXML PunchOutOrderMessage, or any other structured payload; AS2 only handles getting the file there securely and proving it arrived. This is a common point of confusion for teams setting up new trading-partner connections: getting AS2 working (URLs, certificates, MDNs) is a separate project from mapping the actual document content, and a connection can pass AS2 connectivity tests while the underlying EDI or cXML mapping is still wrong.
Frequently asked questions
What does AS2 stand for?
AS2 stands for Applicability Statement 2, the name IETF RFC 4130 gives to this specification. It's the second in a family of EDIINT protocols (AS1, AS2, AS3, AS4) that define secure ways to exchange business documents over different transport layers.
Is AS2 the same thing as EDI?
No. EDI (such as ASC X12 or EDIFACT) refers to the structured document formats used for purchase orders, invoices, and similar transactions, while AS2 is one of several protocols used to transport those documents securely between trading partners. A company can use EDI documents over AS2, a VAN, SFTP, or other transport methods.
How is AS2 different from AS3 and AS4?
AS2 sends messages over HTTP/HTTPS directly between two parties. AS3 does the same but over FTP instead of HTTP, using a client/server model rather than AS2's peer-to-peer connection. AS4 is a newer, SOAP-based OASIS standard designed to be payload-agnostic and interoperate more easily across different vendors' implementations, while preserving AS2's non-repudiation guarantees.
Do both trading partners need AS2 software?
Yes, both sides need an AS2-capable server or a hosted AS2 gateway service configured with their own AS2 ID, URL, and certificate. Many companies outsource this to a managed AS2 provider rather than running their own AS2 server, especially if they only need to connect with a small number of partners.
Why would an AS2 connection fail even though the network is fine?
The most common causes are an expired or mismatched digital certificate, an incorrect AS2 ID on either side, or a mismatch in MDN settings (for example, one side expecting a signed synchronous MDN while the other sends an unsigned asynchronous one). These failures happen at the protocol layer and won't show up as a typical network outage.