EDI concepts
What is AS2 in EDI?
AS2 sends an EDI file directly from one company's server to its trading partner's server over HTTP, signed and encrypted, and the receiver returns a signed receipt called an MDN. It replaces the network mailbox of a VAN with a point-to-point connection per partner. It moves the file; it does not read it, translate it or confirm that its content is right.
Updated
What AS2 does
AS2 (Applicability Statement 2) is the protocol in RFC 4130, published in July 2005. The sender packs the EDI file in a MIME message, signs and encrypts it with S/MIME, and sends it with an HTTP POST to the partner's AS2 URL. The partner answers with a Message Disposition Notification (MDN), a receipt that can be signed and carries a hash of what was received. The RFC names four properties: confidentiality, integrity and authenticity, non-repudiation of origin and non-repudiation of receipt.
AS2 is transport only. GS1's implementation guide for newcomers says it plainly: AS2 "does NOT include the translation or 'mapping' of the data content". The X12 or EDIFACT inside is produced and read by other software. AS2 is one of the three common transports next to a VAN mailbox and SFTP, and the comparison of all three is on what is EDI.
What an AS2 message carries
An AS2 message is an HTTP request with a few headers RFC 4130 makes mandatory, and a body that is the signed and encrypted EDI file. Here is the 856 ship notice from our document pages, interchange 457 from Northfield Supply to Harbor Retail, as it leaves the sender:
POST /as2 HTTP/1.1
Host: as2.harbor-retail.example
AS2-Version: 1.1
AS2-From: NORTHFIELD
AS2-To: HARBORRETAIL
Message-ID: <20261003091500.457@as2.northfield.example>
Disposition-Notification-To: as2@northfield.example
Disposition-Notification-Options: signed-receipt-protocol=required,pkcs7-signature; signed-receipt-micalg=required,sha-256
Content-Type: application/pkcs7-mime; smime-type=enveloped-data
| Header | What it does | What goes wrong |
|---|---|---|
AS2-From, AS2-To |
Names of sender and receiver, 1 to 128 printable ASCII characters | A name that does not match the partner's profile: the receiver rejects the message as unknown |
Message-ID |
Unique ID that the MDN returns as Original-Message-ID |
Reused for different content: the receiver treats a new file as a retry |
Disposition-Notification-To |
Requests an MDN | Missing: no receipt, so no proof of delivery |
Receipt-Delivery-Option |
A URL for an asynchronous MDN; without it the MDN comes back in the same HTTP response | A return URL the sender cannot receive on: the MDN is lost |
AS2-Version |
1.0, or 1.1 for compression per RFC 3274 | Compressed payload to a 1.0 partner |
The AS2 names are separate from the X12 IDs. NORTHFIELD in AS2-From identifies the AS2 endpoint; ZZ*NORTHFIELD in the ISA segment identifies the EDI sender. They often look alike and are configured in two different places.
The MDN, and what it does not say
The receiver decrypts the body, verifies the signature against the sender's certificate and computes a hash of the content, the MIC. It returns the MIC in the Received-content-MIC field of a signed MDN together with the original Message-ID. When the sender's own hash matches, the sender holds proof that this exact file arrived. RFC 4130 defines the disposition as processed or failed, with error modifiers such as decryption-failed, authentication-failed, integrity-check-failed and insufficient-message-security.
The MDN is not a business answer. A processed MDN means the bytes arrived intact. Whether the 856 has a valid hierarchy, a correct SSCC and segment counts that add up is decided afterwards by the partner's translator, which sends a 997 as a separate AS2 message with its own MDN. One outbound document therefore produces three things to match: the MDN, the 997 and, for some partners, an 824 application advice.
| Answer | Comes from | Confirms |
|---|---|---|
| MDN | Partner's AS2 server | File received, decrypted, signature and MIC correct |
| 997 | Partner's translator | X12 syntax accepted or rejected, per group and set |
| 824 | Partner's application | Business content accepted or rejected |
Security settings that both sides have to agree
RFC 4130 allows twelve combinations of signed or unsigned data, encrypted or not, and signed, unsigned or no receipt. Only signed data with a signed MDN gives both kinds of non-repudiation, so that is the combination to agree when a partner leaves it open. The algorithms are agreed per partner. RFC 4130 of 2005 recommends SHA-1 for signatures. S/MIME 4.0 (RFC 8551, April 2019) requires support for SHA-256 and SHA-512 and for AES-128 GCM and AES-256 GCM encryption, and marks tripleDES as historic. An integration that signs with SHA-256 against a partner configured for SHA-1 gets an integrity-check-failed MDN or no MDN at all, while its own log says the file was sent.
GS1's guide lists the items to exchange before the first test: inbound URL or IP and port, the AS2 names, the certificate type and key length, the encryption algorithm, MDN yes or no, signed or not, synchronous or asynchronous, and a technical contact. It recommends ports 4080 for HTTP and 5443 for HTTPS, and warns that random ports are a common problem in new setups.
Certificates expire: a worked example
Every AS2 partner holds your public certificate, and you hold theirs. GS1's guide says production certificates typically expire one to two years after issue, and the replacement has to reach every partner before the old one expires. Take a supplier with 12 AS2 partners whose certificates each last two years, and an own certificate also renewed every two years:
- Partner side: 12 certificates divided by 2 years is 6 renewals a year, on average one every 2 months, each on a date the partner chooses.
- Own side: one renewal every 2 years, but it has to be installed by all 12 partners before the old certificate expires.
- A partner that has not installed the new certificate by then cannot decrypt your files or verify your signature, so each of your outbound documents to that partner fails at once.
Some AS2 software exchanges replacement certificates automatically. GS1 describes this as Certificate Exchange Messaging, which only works when both sides support it. Without it, every renewal is a manual exchange with a test file, scheduled per partner.
Retries and duplicates
When the sender does not get the HTTP response, RFC 4130 says it should repeat the POST with the same content and the same Message-ID, and the receiver should send the earlier MDN again instead of processing the file a second time. The retry interval, the number of attempts and the timeout are left to the trading partner agreement. Two failures follow from that:
- A retry with a new Message-ID. Software that rebuilds the message for each attempt sends a new ID, and the receiver processes the same 856 twice. Two ship notices for one truck mean two expected receipts at the dock.
- Retries that end silently. With, for example, 6 attempts at 15-minute intervals, an 856 sent at 09:15 fails for good at 10:45. If nothing raises an alert, the first sign is the missing 997 or a ship notice that was not there when the goods arrived.
What this means for your integration
AS2 takes the network out of the route, so delivery, receipts and certificates become part of the integration instead of a VAN's job. Every outbound file needs its MDN checked against its Message-ID and MIC, its 997 matched to its control number, and every partner certificate tracked against its expiry date.
We build that into the EDI integration we run for you: one AS2 profile per partner with the agreed algorithms, retries with the same Message-ID, MDNs and 997s matched to each document, and an alert in the dashboard when a receipt is missing or a certificate is about to expire. Tell us which partners ask for AS2.
Frequently asked questions
Is AS2 the same as EDI?
No. EDI is the document format, such as an X12 856 or an EDIFACT DESADV. AS2 is one way to deliver that file, defined in RFC 4130. The same 856 can travel over AS2, over SFTP or through a VAN mailbox without a single character of it changing.
Does an AS2 MDN replace the 997?
No. The MDN confirms that the file arrived, decrypted and passed the signature and integrity check. The 997 functional acknowledgment comes from the partner's translator and says whether the X12 inside was accepted. A file can get a processed MDN and a rejecting 997.
What is the difference between AS2 and a VAN?
A VAN holds files in mailboxes that each side collects from, and bills per document or per kilocharacter. AS2 posts the file directly to the partner's server, with no network operator in between. Each AS2 partner needs its own setup: URL, AS2 identifiers, certificates and the agreed security options.
Do I need my own server for AS2?
You need an AS2 endpoint that the partner can reach at any time, because the partner pushes files to you. GS1's AS2 implementation guide lists a 24x7 internet connection, a static IP address and dedicated firewall ports among the requirements. The endpoint can be run for you; it does not have to sit in your own office.
Which retailers accept AS2?
Walmart lists AS2 as one of four connection types for drop-ship vendors, as a direct connection between Walmart and the vendor. Other retailers state their accepted connections in their EDI guides or supplier portals; the Walmart EDI page shows how one retailer words it.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase