The language-translator analogy

Think of EDI translation like a language translator for computers. Your system "speaks" one language (maybe a CSV export from your ERP, or a JSON payload from your e-commerce platform). Your partner's system might speak another. The translation software ensures everyone is speaking the same EDI language.

What a translator actually does

  • Reads inbound EDI envelopes and validates them against the standard.
  • Maps standard fields to your internal data model.
  • Generates outbound EDI from your internal data, padding fields, applying delimiters and assembling envelopes.
  • Issues acknowledgments (997, CONTRL) when required.

On-prem vs API-based

Legacy translators run as on-premise software, often paired with a separate communications module. API-based translators (like EDIFlux) expose translation as a REST endpoint your application can call. Same standards, fewer servers.

How EDIFlux translates

Send raw EDI to POST /api/public/edi/translate with a Bearer API key. EDIFlux detects the standard (X12 vs EDIFACT) automatically, parses envelopes and transactions, and returns a clean JSON document.