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.