ModernEDI Integration API (1.2.0)

Customer-facing integration endpoints for ModernEDI tenants. Use this API when your ERP, WMS, integration service, or internal automation needs to receive mapped inbound documents, send AS2 replies, send standalone outbound AS2 documents, or inspect transaction evidence.

ModernEDI is designed around a simple operating model: receive partner AS2/X12 traffic, map inbound documents into the ERP, WMS, accounting, XML, JSON, or custom format your operation uses, then treat that mapped document as your source of truth. Replies such as invoices and ASNs are sent from that business record with /as2/reply.

A typical inbound 850 to outbound 810 loop is:

1. Poll GET /mapped-outputs for mapped inbound documents.
2. Store or process the returned payload in your system.
3. Call POST /mapped-outputs/{id}/ack after your system has accepted the mapped output.
4. Build the reply document from your system of record and call POST /as2/reply.
5. Use /integration/transactions to confirm the inbound document, mapped output, AS2 receipts, 997s, and reply stay linked.

If you prefer push delivery, configure a per-partner mapped-output webhook in the ModernEDI workspace. ModernEDI sends the same mapped-output message shape to your HTTPS endpoint and automatically acknowledges the queue item only when your endpoint returns a 2xx response. Failed webhook attempts leave the message available through the pull API.

Push webhook requests include X-ModernEDI-Event, X-ModernEDI-Delivery-Id, X-ModernEDI-Timestamp, and X-ModernEDI-Signature. The signature is sha256=<hex hmac> over <timestamp>.<raw request body> using the partner webhook signing secret.

/as2/send is also available when your system needs to send a standalone outbound X12 interchange that is not replying to a received document.

Key fields in the mapped-output loop:

• id: mapped output id used in the /mapped-outputs/{id}/ack path.
• receiptHandle: token from the latest poll, required when marking mapped output as received.
• messageId: original inbound AS2 message id; use it as originalMessageId for /as2/reply.
• transactionKey: transaction identifier within the AS2 message, usually GS06#ST02.
• mappedOutputKey: unique mapped-output key inside the transaction.
• payload: mapped document body; parse it according to contentType.
• replyToMessageId: present on outbound replies and points back to the inbound message.

For transaction evidence, start with the inbound transaction detail and show the original X12 document, mapped output records, MDN and 997 details, outbound replies from relatedTransactions, and the reply transaction's own MDN and 997 details.

Common failures to handle include missing or invalid API keys, unknown partner names, invalid X12 payloads, originalMessageId not found, partner AS2 delivery failure, and mapped output returned again because it was not marked received before the visibility timeout.