Applicability Statement 2 (AS2) is a standardized way to move data securely over the internet. A combination of encrypted keys, unique IDs, and receipts are used to ensure security.
- Unique ID: You will create an ID between 1-128 characters. It can include special characters, numbers, and letters. Tip: There should be one unique ID for your production connections and another for your sandbox connections.
- MDN: An MDN is an optional return receipt. Note: An MDN only verifies that files were received, not the nature of the data. MDNs can be:
- Synchronous: When a message is received through an HTTP response, the MDN is sent to the URL that the message came from. Note: We only accept synchronous MDNs through integrator.io.
- Asynchronous: The MDN will be sent at a later time and to a different URL than the one the message originally came from.
- X.509 certificate and public key: The certificate contains an algorithm-based public key, an identity, like a hostname or an organization, and a signature. The X.509 can come in many formats, but to be passed through our platform, it has to be in .pem form. You can convert your certificate to .pem with the OpenSSL toolkit.
- The signature: Certificates can be self-signed or signed by a certificate authority. When certificates are signed by a certificate authority, the public key inside of it has been validated and can be trusted to establish secure connections.
- The keys: Before 2 parties start to exchange messages over an AS2 connection, they share their public keys with each other. The public key is paired with a private key. Only the person who owns the private key has access to it, which means that they’re the only ones who can decrypt messages sent with its corresponding public key.
- .pem From: This is what .pem format looks like:
- X.509 private key: You will use the algorithm-based private key to decrypt messages that were encrypted with the public key. Only private keys that correspond to the public keys will be able to open the message. The key must be in .pem form:
Before you can integrate with an AS2 connection
To be able to create an integration with your trading partner through an AS2 connection, you will have to have traded the necessary info with them, like the certificates and IDs. You and your trading partner will also need to come to an agreement on which algorithms to use for signing and decryption so that each endpoint knows what to expect.
How integrator.io syncs files sent with AS2
We handle messages sent through an AS2 connection in stages that follow this order:
- Receive a message: There is only one URL integrator.io uses to receive messages: https://api.integrator.io/v1/as2.
- Check the receiver: We look at the unique ID of the recipient. The ID tells us which integrator.io customer is meant to receive this message.
- Example: Your partner, Walmart, sends you a file of sales orders. When Walmart sends the file, your unique ID is in one of the headers.
- Check the sender: We look at the unique ID of the sender. The combination of the sender and recipient IDs tells us which connection the info belongs to.
- Example: When your partner, Walmart, sends a file of sales orders to you through an AS2 connection, their ID will be in the AS2 message header.
- Example: You have an AS2 connection set up with Walmart, and you're using that connection in 2 different flows: one flow that syncs your Walmart sales orders with your NetSuite ERP, and another that syncs your Walmart change orders with your Shopify shipping orders. When Walmart sends you a message through integrator.io, the routing rules you've defined scan the message and find the number than identifies the message as a sales order, so the message runs your flow for sales orders.
- Choose the flow: After we’ve identified who the message is to, who it’s from, and what kind of data files are being sent, we send the files to the intended flow.