ModernEDI

Docs / Getting Started

Your first partner document

A retailer sends an X12 850 purchase order. You want your application to receive a useful order document, not a string of EDI segments. Start by configuring that partner and testing one incoming map.

No scenario, external Git repository, or CLI is required.

You need a provisioned workspace, the partner's identifiers and connection details, and a map for the document you want to process. Add other maps as you need other document types or directions.

1. Identify the partner and connection

In the workspace's Getting Started path, create the trading partner and configure the AS2 connection. Use values supplied by the partner: AS2 IDs, endpoint URL, public certificate, signing/encryption requirements, and receipt preferences. Set the X12 identifiers and document version that match their interchange.

Share your workspace's AS2 endpoint and public certificate with the partner. Do not share private keys or ModernEDI API keys. Confirm whether the agreed traffic is test or production; an AS2 receipt alone does not mean your business document mapped successfully.

2. Test one mapping in the browser

  1. Open Mapper and choose the partner and document.For this example, use an incoming 850 Purchase Order map with the X12 version your partner uses.
  2. Load a representative sample.Include the loops and values you actually need, such as the purchase-order number, ship-to address, item identifiers, quantities, and prices. Use synthetic or appropriately sanitized documents for shared demonstrations.
  3. Run the map and inspect its output.Check the business values, not just whether the map compiled. Use the reference and trace tools to see where values came from. A successful sample run does not send a document to your partner.
  4. Try the important variations.For example, an order with several lines and an order with an optional address field omitted. Saving these browser samples is useful authoring work; it is not automatically a Git-managed regression suite.

You can practice without an account in the live Mapper demo. Its example workspace is not a live partner connection. See Mapper built-ins for expression signatures and examples.

3. Review and deploy the mapping

Mapper saves editing drafts automatically. Check its save status to confirm your work is retained. Saving a draft does not replace the live map. Use Review & deploy to inspect the proposed configuration change, resolve any diagnostics, and confirm deployment when you are ready.

ModernEDI validates against the workspace's current configuration. If another browser or a connected repository changed the same configuration, resolve the conflict and review again rather than overwriting it. After applying, wait for runtime activation to complete before expecting new traffic to use the change. Change history shows the saved operation and its activation progress.

4. Confirm the first real document

Arrange an agreed sample with the partner. In Activity, open the transaction and check:

  • The document came from the expected partner and has the expected X12 version and transaction set.
  • The incoming mapping succeeded and the output has the correct business values.
  • The required transport receipt and functional acknowledgment have the expected results.

If a check fails, inspect the corresponding transaction details. A received AS2 message, accepted X12 acknowledgment, and successful mapping answer different questions; none substitutes for the others.

5. Connect your application when you are ready

Use mapped-output polling or webhooks to deliver the business document to your ERP, WMS, or other system. Your application remains responsible for fulfillment, order changes, and invoicing.

When you need to return an invoice, add an outgoing 810 map. Your backend sends its JSON, XML, or text source document to /reply; ModernEDI maps it to X12 and handles delivery and transaction linkage. Use /send for a standalone outgoing document.

Create a least-privilege Integration API key for that backend and keep it in a server-side secret store. Never put it in browser JavaScript, a repository, or a sample document. The Integration API reference explains authentication, scopes, polling, and webhook verification.

You can stop here—or build on it

Once your first mapping works, you can optionally save sanitized inputs and expected outputs as Mapper test cases. Rerunning them helps catch accidental mapping changes. They are not required for deployment or dependent on Git; learn how to test and deploy a mapping safely.

A partner and the required mappings are enough to operate this integration. Add a scenario when you want to prove that an order and its invoice belong together. Connect external Git when you want to synchronize reviewed configuration with your repository. Neither changes the role of your maps.