AS2

The AS2 node sends signed and encrypted AS2 messages to trading partners over HTTP/HTTPS. AS2 (Applicability Statement 2) is the de facto standard for secure B2B document exchange — most commonly used to transmit EDI documents to retailers, carriers, suppliers, and other partners that require signed, encrypted, and acknowledged delivery.

Overview

The AS2 node is essential when you need to:

Transmit EDI to trading partners - Send X12 or EDIFACT documents to partners that require AS2 transport
Sign and encrypt payloads - Apply PKCS#7 signing and encryption using your sender certificate and the partner's encryption certificate
Validate delivery with MDNs - Request and verify Message Disposition Notifications (signed or unsigned) returned by the partner
Verify message integrity - Compare the partner's Received-Content-MIC against the locally computed MIC to detect tampering or corruption
Send any signed/encrypted payload - The node is content-type agnostic; XML, JSON, binary attachments, and other formats are supported alongside EDI

Configuration

AS2-From

The sender's AS2 identifier — the value placed in the AS2-From header. This is the AS2 identity your partner has configured to recognize you. It is typically a short alphanumeric string assigned during partner onboarding (e.g., ACME-PROD).

AS2-To

The partner's AS2 identifier — the value placed in the AS2-To header. Use the identifier the partner has provided for their own AS2 endpoint.

Partner URL

The HTTPS (or HTTP) URL of the partner's AS2 receiver endpoint. AS2 payloads are signed and encrypted at the application layer, so partners frequently expose their endpoints with self-signed or otherwise untrusted TLS certificates. The node accepts whatever TLS certificate the partner presents and logs its identity (CN, issuer, fingerprint, validity dates) so that the trust decision is auditable.

Message Source

Choose where the payload comes from:

Text - Provide the message content directly. Use this when an upstream node (e.g., EDI Create Message, Code, Transform) has produced the payload in memory.
File - Reference a file already staged in workflow temporary storage. Use this when the payload was produced by a node that emits a file (e.g., FTP Download, PDF generators).

Message / Source File Path

When Message Source = Text, supply the payload content in the Message field.
When Message Source = File, supply the storage path in the Source File Path field.

File Name

The filename advertised in the AS2 payload's Content-Disposition header. This is what the partner sees and often uses for archival or routing. If omitted:

For file sources, the basename of the source path is used.
For text sources, an auto-generated name like as2-1714253420123-a4b1.edi is used (the extension is derived from the content type).

Content Type

The MIME content type of the payload. Defaults to application/EDI-X12. Common values:

Content Type	Use Case
`application/EDI-X12`	X12 EDI documents (default)
`application/EDIFACT`	EDIFACT EDI documents
`application/xml`	XML payloads
`application/octet-stream`	Binary payloads

Subject

Optional subject line for the AS2 message. Some partners log this for traceability; it has no protocol-level meaning.

Credential

The AS2 node requires a configured AS2 credential that bundles the certificates and policy used for the exchange:

Field	Description
Sender Certificate	Your certificate + private key. Used to sign the outbound payload.
Partner Encryption Certificate	The partner's public certificate. Used to encrypt the outbound payload.
Partner Signer Certificate	(Optional) The partner's signing certificate. Required only if you want to verify signed MDNs returned by the partner.
Preferred MIC Algorithm	One of `sha256` (default), `sha384`, `sha512`, or `sha1`. Determines the digest used for the Message Integrity Check.
Encryption Algorithm	Symmetric cipher used to encrypt outbound payloads. One of `aes256-CBC` (default), `aes192-CBC`, `aes128-CBC`, or `3des-CBC`.
Request MDN	Whether to request a Message Disposition Notification from the partner. Defaults to `true`.
Request Signed MDN	`required`, `optional` (default), or `none`. Controls whether a signed MDN is requested and whether unsigned MDNs are accepted.
Validate MIC	Whether to fail the send if the partner's Received-Content-MIC does not match the locally computed MIC. Defaults to `true`.
Validate MDN Signature	Whether to verify the signature on signed MDNs against the configured Partner Signer Certificate. Defaults to `true`.

Certificate Expiry Monitoring

The node automatically inspects the partner encryption certificate before each send. Sends are blocked when the certificate has already expired. Sends within 30 days of expiry succeed but emit a near-expiry warning event so operations can rotate certificates before service is disrupted.

Output

The node returns a structured result describing the outcome of the exchange:

{
  "statusCode": 200,
  "status": "delivered",
  "detail": "automatic-action/MDN-sent-automatically; processed",
  "body": "<raw partner response body>",
  "rawResponse": {
    "statusCode": 200,
    "body": "...",
    "contentType": "multipart/signed; ..."
  }
}

Status Values

Status	Meaning
delivered	The partner accepted the message. If an MDN was requested, the disposition was `processed` and (when validation is enabled) the MIC and signature checks passed.
processing-error	The partner returned an MDN with a `failed` or `processed/error` disposition. Inspect `detail` for the partner-supplied reason.
signature-error	The MDN signature did not verify, the partner returned an unsigned MDN when a signed one was required, or the multipart structure was malformed.
mic-mismatch	The partner's Received-Content-MIC does not match the locally computed MIC, indicating the payload was altered or corrupted in transit.
transport-error	The HTTP request itself failed, the partner returned a non-2xx status, or the partner encryption certificate has expired.

Example Usage & Common Use Cases

Send an Outbound EDI Document

Transmit an X12 document produced by the EDI node to a trading partner:

AS2-From: ACME-PROD
AS2-To: PARTNER-EDI
Partner URL: https://as2.partner.com/inbound
Message Source: Text
Message: {{steps.createEdi.output.message}}
Content Type: application/EDI-X12
Credential: Acme → Partner AS2

Output: { status: "delivered", ... }

Send a Pre-Generated File

Send a file staged in workflow storage by an upstream node:

AS2-From: ACME-PROD
AS2-To: PARTNER-EDI
Partner URL: https://as2.partner.com/inbound
Message Source: File
Source File Path: {{steps.generateInvoice.output.filePath}}
File Name: invoice-{{data.invoiceNumber}}.edi
Credential: Acme → Partner AS2

Output: { status: "delivered", ... }

Branch on Delivery Outcome

Use the returned status to drive downstream logic:

[EDI: Create 214] → [AS2: Send] → [If: status == "delivered"]
                                    ↓ true                ↓ false
                             [Mark Sent]            [Send Email: Operations Alert]

Send an XML Payload

Transmit a non-EDI payload by overriding the content type:

AS2-From: ACME-PROD
AS2-To: PARTNER-XML
Partner URL: https://as2.partner.com/xml
Message Source: Text
Message: {{steps.buildXml.output.body}}
Content Type: application/xml
File Name: order-{{data.orderId}}.xml
Credential: Acme → Partner AS2 (XML)

How It Works

Resolve credentials - Load the sender certificate, partner encryption certificate, and (if configured) partner signer certificate from the credential store.
Inspect partner certificate - Check the partner encryption certificate's notAfter date. Expired certs abort the send; near-expiry certs emit a warning event.
Build the MIME part - Wrap the payload in a MIME body part with the configured Content-Type and Content-Disposition headers, canonicalizing line endings to CRLF.
Sign - Compute a PKCS#7 detached signature over the MIME part using the sender's private key and the configured MIC algorithm.
Compute MIC - Compute the Message Integrity Check by digesting the canonical signed content. The MIC is recorded for later comparison against the partner's MDN.
Encrypt - Wrap the signed multipart in a PKCS#7 enveloped-data structure encrypted to the partner's encryption certificate.
POST to partner - Send the encrypted payload to the partner URL with the appropriate AS2 headers (AS2-From, AS2-To, AS2-Version: 1.2, Disposition-Notification-To, Disposition-Notification-Options, etc.).
Parse the MDN - If an MDN was requested, parse the partner's response. For signed MDNs, verify the signature against the partner signer certificate. Compare the Received-Content-MIC against the local MIC.
Return result - Emit a structured result with the resolved status and detail.

MDN Handling

Signed vs Unsigned MDNs

The requestSignedMdn setting controls how MDN signatures are negotiated:

Setting	Behavior
required	The partner is asked for a signed MDN. Unsigned MDN responses fail with `signature-error`.
optional (default)	The partner is asked for a signed MDN but unsigned responses are accepted.
none	No MDN signature is requested or validated.

MIC Validation

When validateMic is enabled (default), the node compares its locally computed MIC against the Received-Content-MIC header in the partner's MDN. A mismatch returns mic-mismatch and indicates either tampering or — more commonly — a line-ending or canonicalization difference between the two implementations. Disabling MIC validation may be necessary for partners with known canonicalization quirks, but should be considered a last resort.

MDN Signature Verification

When validateMdnSignature is enabled (default) and the partner returns a multipart/signed MDN, the node verifies the detached PKCS#7 signature against the configured partner signer certificate. If no partner signer certificate is configured, signed MDNs cannot be verified and the send fails with signature-error.

Common Patterns

Outbound EDI with AS2 Transport

The standard pattern for sending EDI to partners that require AS2:

[Trigger] → [EDI: Create Message] → [AS2: Send] → [If: status == "delivered"] → [Update System of Record]
                                                       ↓ false
                                                 [Alert / Retry Logic]

Inbound Acknowledgment Loop

Acknowledge inbound EDI received over a separate channel (FTP, webhook, etc.) and return the 997 to the partner via AS2:

[FTP Trigger: New File] → [EDI: Read Message] → [EDI: Create 997] → [AS2: Send]

Multi-Partner Distribution

Loop over a list of partners and send the same document to each:

[Build Document] → [Loop: partners] → [AS2: Send (with partner credential)] → [Collect Results]

Best Practices

Certificates

Provision both sender and partner certs in advance - The credential must reference your sender certificate (with private key) and the partner's encryption certificate before the first send.
Add the partner signer certificate - Configure it whenever the partner sends signed MDNs, or signed MDN verification will fail.
Plan for rotation - Track the partner's certificate notAfter date and coordinate rotation before expiry. The near-expiry warning is your 30-day notice.
Treat sender private keys as sensitive - They are stored encrypted in the credential service; never commit them to workflow code or logs.

MDN Policy

Keep MDNs enabled - Disabling MDNs (requestMdn: false) means the node accepts a 2xx HTTP status as success, with no application-layer confirmation.
Default to requestSignedMdn: optional - It maximizes interoperability while still verifying signatures from partners that send them.
Use requestSignedMdn: required for high-trust integrations - When the partner reliably returns signed MDNs, enforcing this catches misconfiguration on either side.

Error Handling

Branch on status not statusCode - A 2xx HTTP status with a processing-error MDN is still a failure.
Surface the detail field in alerts - It carries the partner-supplied reason for failures, which is essential for triage.
Retry transport errors, not processing errors - transport-error is often transient (network, partner outage); processing-error and signature-error indicate misconfiguration that retrying will not resolve.

Troubleshooting

Common Issues

signature-error: MDN is signed but no partnerSignerCertificate configured - The partner returned a signed MDN but no partner signer certificate is configured on the credential. Add it, or set validateMdnSignature: false to disable verification.
mic-mismatch - Check whether the partner is canonicalizing line endings differently. The node canonicalizes to CRLF before hashing; some partners hash the wire bytes after their own normalization.
transport-error: certificate-expired - The partner's encryption certificate has passed its notAfter date. Obtain a fresh certificate from the partner and update the credential.
transport-error: HTTP 401/403 - The partner does not recognize your AS2-From identifier or your sender certificate. Confirm onboarding is complete on the partner side.
signature-error: partner returned unsigned MDN but requestSignedMdn=required - Either the partner is not configured to sign MDNs, or the request did not negotiate signing correctly. Lower the requirement to optional or work with the partner to enable signing.

Debugging Tips

Inspect rawResponse - The full partner response (status code, body, content type) is returned alongside the parsed result. For unparseable MDNs, the raw body usually contains a human-readable error.
Check CloudWatch logs - The node emits structured events (as2_send_request_built, as2_send_request_posted, as2_send_response_received, as2_mdn_parsed, as2_send_error) that record every step of the exchange, including the computed MIC and the negotiated headers.
Audit TLS trust - The as2_partner_tls_inspected event records the partner's TLS certificate fingerprint and CN. Use this to verify you are connecting to the expected endpoint.
Test with a known-good payload - Round-trip a simple test document with the partner before connecting live data feeds.

Overview​

Configuration​

AS2-From​

AS2-To​

Partner URL​

Message Source​

Message / Source File Path​

File Name​

Content Type​

Subject​

Credential​

Output​

Status Values​

Example Usage & Common Use Cases​

Send an Outbound EDI Document​

Send a Pre-Generated File​

Branch on Delivery Outcome​

Send an XML Payload​

How It Works​

MDN Handling​

Signed vs Unsigned MDNs​

MIC Validation​

MDN Signature Verification​

Common Patterns​

Outbound EDI with AS2 Transport​

Inbound Acknowledgment Loop​

Multi-Partner Distribution​

Best Practices​

Certificates​

MDN Policy​

Error Handling​

Troubleshooting​

Common Issues​

Debugging Tips​