In this article
Talk to our experts- AS2
- AS2 (Applicability Statement 2) is an internet protocol for exchanging electronic data interchange (EDI) and other structured business data securely over HTTP. In a secure AS2 exchange, the sender signs and encrypts the message, and the receiver returns a signed receipt, a Message Disposition Notification (MDN), giving the sender evidence the message was received and authenticated or decrypted properly.
Also called: Applicability Statement 2, AS2 protocol
How it works
AS2 is defined in RFC 4130, an Internet standards track document published in July 2005. It describes how to exchange structured business data securely using HTTP instead of email (SMTP). The data may be XML, EDI in the X12 or UN/EDIFACT formats, or other structured data. It is called AS2 because it is the second applicability statement, produced after AS1 (RFC 3335), which covers SMTP.
Each message is sent with an HTTP POST. The receiving side unpacks it and replies with an MDN, either in the HTTP response or by a new HTTP POST to the sender. RFC 4130 calls this exchange the secure transmission loop:
The AS2 secure transmission loop
The sender signs and encrypts the EDI data with S/MIME, requests a signed receipt and keeps the message ID and digest.
The receiver decrypts the message and verifies the signature, confirming the data's integrity and the sender's identity.
The receiver returns a signed MDN containing the hash of the received message, in the HTTP reply or a separate POST.
The sender verifies the signed MDN and checks that its digest matches the stored value, the condition RFC 4130 sets for non-repudiation of receipt.
The standard leaves room for choice: partners can exchange messages with or without a digital signature, and with or without a request for a receipt.
What an AS2 connection needs
- Certificates: X.509 certificates are required. Partners exchange public keys as part of setting up the trading partnership. A certification authority is optional, and certificates may be self-signed.
- System identifiers: AS2-From and AS2-To headers help the receiving system identify the sending system.
- Partner records: each side keeps a database of public keys and maps each EDI trading partner ID to that partner's email address and HTTP URL.
- Receipt type: a synchronous MDN comes back on the same connection as the original POST; an asynchronous MDN arrives on a separate HTTP, HTTPS or SMTP connection.
AS2 vs. the EDI documents it carries
AS2 is the transport, not a document type. The documents inside are EDI transaction sets, such as an EDI 850 purchase order. That is why one exchange can produce two acknowledgments:
- The MDN confirms that the AS2 message itself was received, and when signed, gives the sender evidence that it was authenticated or decrypted properly.
- The X12 997 functional acknowledgment reports the results of the syntax check on the transaction sets inside. X12 notes that the 997 does not cover the meaning of the data.
Common problems
RFC 4130 defines error values a receiver can return in the MDN when a message cannot be processed:
- decryption-failed: the receiver could not decrypt the message contents.
- authentication-failed: the receiver could not authenticate the sender.
- integrity-check-failed: the receiver could not verify content integrity.
- unexpected-processing-error: a catch-all for any other processing error.
The RFC's examples also show a duplicate-document warning, sent when an identical message already exists at the destination server. If the sending side fails to read the server's HTTP response and the condition is transient, the RFC says the POST should be repeated with identical content, including the same Message-ID.
Example
A retailer sends a distributor an EDI 850 purchase order for 40 cases over AS2. The distributor's AS2 software decrypts the message, verifies the retailer's signature and sends back a signed MDN in the same HTTP session, a synchronous receipt. The EDI software then checks the 850's syntax and returns a 997. The retailer now holds two confirmations for one order: the MDN for the delivery of the message, and the 997 for the transaction inside it.
On Shopify
AS2 runs between your EDI software and your trading partner's system. Shopify B2B syncs orders, customer data, inventory, product catalogs and pricing with external business systems through an integration, and Shopify describes three methods:
- Direct integrations from the Shopify App Store, for select ERP, accounting and product information management systems.
- Integration platform as a service (iPaaS) providers, which work as intermediaries and handle data transformation and synchronization.
- Custom integrations built on Shopify's B2B APIs, for systems without a pre-built integration.
How Uncap helps
Uncap's Shopify EDI integration guide maps the order flow: a trading partner sends an 850 purchase order through their EDI network via AS2, SFTP or a value-added network (VAN), and EDI middleware receives the 850 and translates it into a Shopify order through the Shopify Orders API.
Sources
Frequently asked questions
What does AS2 stand for?
AS2 stands for Applicability Statement 2. RFC 4130 explains the name: it is the second applicability statement, produced after AS1, which covers the same kind of exchange over email (SMTP).
What is AS2 and how does it work?
AS2 is a protocol for sending EDI and other business data securely over HTTP. In a secure exchange, the sender signs and encrypts the message and posts it to the partner, who decrypts it, verifies it and returns a receipt called an MDN.
What is AS2 and AS4?
AS2 is the RFC 4130 protocol for sending EDI and other business data over HTTP. AS4 is an OASIS Standard for web services B2B messaging, dated 23 January 2013. It profiles ebMS 3.0 and was developed to carry on the principles and simplicity that made AS2 successful, while adding better compliance with web services standards, message pulling and a built-in receipt mechanism.
