EDI to JSON Parser - X12 & EDIFACT (850/810/856/997)

EDI to JSON turns raw B2B EDI interchanges — both ANSI ASC X12 and UN/EDIFACT — into clean, structured, agent-ready JSON. Drop in a purchase order, invoice, ASN or acknowledgment and get back typed fields (parties, line items, dates, amounts), the full segment tree, and an optional structural validation report. No mapping project, no translator license, no onboarding.

What does EDI to JSON do?

It parses a single EDI interchange into one structured JSON record. It supports the core commerce transaction sets:

• X12: 850 Purchase Order, 810 Invoice, 856 Advance Ship Notice (ASN), 997 Functional Acknowledgment
• EDIFACT: ORDERS (purchase order), INVOIC (invoice)

For each interchange it returns the interchange envelope (sender, receiver, control number, date/time, standard/version), a list of transaction sets — each with a typed parsed summary and the raw segments list — plus a validation block that checks envelope balance, ST/SE and UNH/UNT segment counts, and control-number matching, and returns an error list. You can send EDI by URL, by uploaded file, or inline as text — ideal for data pipelines and AI agents calling it over the Apify API/MCP. Runs on the Apify platform with API access, scheduling, integrations and monitoring built in.

Scope & safety: this Actor handles commerce EDI only. Healthcare / HIPAA X12 sets (837, 835, 270, 271, 276, 277, 278, 834, 275) carry PHI and are refused — their contents are never parsed or emitted. It operates only on data you supply; it does no scraping, requires no login, and harvests no personal data.

Why use EDI to JSON?

• Skip the EDI translator. Traditional EDI software (Cleo, SPS Commerce, TrueCommerce, Stedi) means license fees, setup projects and per-partner mapping. This is pay-per-file parsing you can call in one HTTP request.
• Agent- and pipeline-friendly output. Flat, typed JSON — no HTML, no nested junk — that an LLM or an ETL job can consume directly.
• Catch bad interchanges early. Structural validation flags miscounted segments, unbalanced envelopes and mismatched control numbers before they break a downstream import.
• Both standards, one Actor. X12 and EDIFACT in a single call, with automatic format detection and separator handling (including EDIFACT UNA service-string advice and release characters).

How to use EDI to JSON

1. Open the Actor and go to the Input tab.
2. Provide your EDI one of three ways: paste it into Inline EDI text, add public EDI URLs, or upload files and pass their key-value store keys.
3. Leave Structural validation on (default) to get an error report, or turn it off to parse only.
4. Click Start. Each interchange becomes one row in the Output dataset.
5. Download the results as JSON, CSV, Excel or HTML, or read them over the API/MCP.

Input

Field	Type	Description
ediText	array of strings	Raw EDI interchanges passed inline (X12 or EDIFACT). Best for API/agent callers.
ediUrls	array of URLs	Public URLs of EDI files to download (with retries) and parse.
keyValueStoreKeys	array of strings	Keys in the run's key-value store holding EDI bytes — how uploaded files are passed.
validate	boolean	Run structural validation and return an error list. Default true.

Example input:

{
  "ediText": [
    "ISA*00*          *00*          *ZZ*ACMEBUYER      *ZZ*SUPPLYCO       *240115*1200*U*00401*000000001*0*P*>~GS*PO*ACMEBUYER*SUPPLYCO*20240115*1200*1*X*004010~ST*850*0001~BEG*00*NE*PO10001**20240115~N1*BY*ACME CORP*92*ACME01~PO1*1*10*EA*9.99*PE*BP*WIDGET-1~CTT*1~SE*6*0001~GE*1*1~IEA*1*000000001~"
  ],
  "validate": true
}

Output

One dataset item per interchange. You can download the dataset in various formats such as JSON, HTML, CSV, or Excel. A simplified X12 850 result:

{
  "source": "ediText[0]",
  "status": "ok",
  "format": "X12",
  "transactionCount": 1,
  "interchange": {
    "sender": "ACMEBUYER",
    "receiver": "SUPPLYCO",
    "controlNumber": "000000001",
    "date": "240115",
    "time": "1200",
    "standard": "X12 00401"
  },
  "transactionSets": [
    {
      "type": "850",
      "name": "Purchase Order",
      "controlNumber": "0001",
      "parsed": {
        "purchaseOrderNumber": "PO10001",
        "date": "20240115",
        "parties": [{ "entityCode": "BY", "name": "ACME CORP", "idQualifier": "92", "id": "ACME01" }],
        "lineItems": [
          { "lineNumber": "1", "quantity": "10", "unit": "EA", "unitPrice": "9.99", "productId": "WIDGET-1" }
        ],
        "totalLineItems": "1"
      },
      "segments": [{ "tag": "BEG", "elements": ["00", "NE", "PO10001", "", "20240115"] }]
    }
  ],
  "guardrail": { "refused": false, "skippedSets": [], "reason": null },
  "validation": { "checked": true, "valid": true, "errorCount": 0, "errors": [] },
  "meta": { "elementSeparator": "*", "componentSeparator": ">", "segmentTerminator": "~", "segmentCount": 12, "functionalGroups": 1 }
}

Output fields

Field	Description
source	The input reference (URL, key, or inline label).
status	ok if ≥1 in-scope transaction set parsed; error otherwise.
format	X12, EDIFACT, or null.
interchange	Envelope: sender, receiver, control number, date/time, standard.
transactionSets[]	Parsed transaction sets: type, name, controlNumber, typed parsed summary, raw segments.
transactionCount	Number of in-scope transaction sets parsed (the billable unit).
guardrail	Healthcare/PHI refusal report (refused, skippedSets, reason).
validation	checked, valid, errorCount, and an errors[] list ({level, code, message}).
meta	Separators used, segment count, functional-group count.

Pricing

This Actor is billed pay-per-event: one charge per successfully parsed interchange (a non-empty result). Files that are unrecognized, empty, or refused by the healthcare/PHI guardrail are returned as error rows and are never charged. Parsing is pure in-container compute (no proxy, no external calls), so runs are fast and cheap; batching many interchanges into one run amortizes startup cost further. See the run's Output and the platform's usage view for exact figures.

Tips and advanced options

• Batch many interchanges in a single run (multiple ediText entries or URLs) to minimize per-run overhead.
• Set a max-charge limit on the run; the Actor stops before doing further unbilled work once the cap is reached.
• Turn validate off if you only need the parsed data and want to skip the structural report.
• EDIFACT with a custom UNA service-string advice (non-default separators, release character) is handled automatically.

FAQ, disclaimers and support

• Which EDI versions? X12 004010-era commerce sets (850/810/856/997) and EDIFACT D.96A-style ORDERS/INVOIC are the tested v1 scope; other versions of the same sets generally parse at the envelope/segment level.
• Does it handle healthcare EDI (837/835/270…)? No — by design. Those carry PHI and are refused; their contents are never parsed or emitted.
• Is any data stored or sent anywhere? No. It only processes the EDI you supply and writes the JSON result to your dataset. No scraping, no auth, no personal-data harvesting.
• Found an issue or need another transaction set? Use the Issues tab — custom sets (e.g. 855, 940, DESADV) can be added on request.