EDI Gateway
Talk X12 to your carriers + shippers without building it yourself. Toretto's EDI gateway ingests freight invoices + shipment status, emits payment remittance + functional acks, and surfaces every parse failure for operator review. One more integration point that just works.
Supported transaction sets
EDI 210 · Inbound
Freight Invoice
The carrier's invoice as X12. Parses into our invoice table for the audit agent to pick up automatically.
EDI 214 · Inbound
Shipment Status
Pickup, in-transit, delivery events. Each AT7 segment fans into a tracking event — and a map position if the carrier included lat/lon.
EDI 204 · Inbound
Load Tender
Shippers offering you a load. Parsed and stored today; full accept/reject workflow ships with the TMS tender waterfall.
EDI 997 · Both
Functional Acknowledgment
We emit one for every file you send us that we parsed successfully. We parse your partners' 997s to correlate back to the outbound they're acking.
EDI 820 · Outbound
Payment Remittance
Pairs with every NACHA ACH batch from Carrier Payment. The carrier matches the wire payment to specific invoices without a phone call.
How it works
- Configure a partner. SFTP host + port + username + password or private key + inbound/outbound directories. Credentials encrypted at rest with AES-256-GCM.
- Gateway polls. Every minute (or per-partner interval), the gateway connects, lists new files, downloads + uploads each to S3, and enqueues a parse task.
- Parse + route. ISA envelope validated, control numbers extracted for dedup + ack correlation. Transaction-set parser runs per document type. Downstream rows land in the right table (invoices, tracking events, tender stub).
- Acknowledge. A 997 Functional Ack fires back to the partner referencing their GS control number. They see the confirmation within seconds of the file landing.
- Monitor + recover. Every message shows up on the /edi dashboard. Parse failures land in the dead-letter queue with the raw payload + failure reason — an operator resolves or reparses.
Why a separate service
- Runtime isolation. EDI ingress is long-running SFTP polling — it belongs on ECS Fargate, not Lambda. Keeping it in its own repo means parse failures or a broken partner can't cascade into audit / payment flows.
- Dependency isolation. X12 parsing + paramiko + future AS2 libraries are heavy deps toretto-api and toretto-workers don't need. Splitting keeps the rest of the platform's cold-start budgets intact.
- Dead-letter by design. Every parse failure lands as an addressable row with the raw payload on S3 + a failure reason. Operators can reparse after a gateway fix without losing anything.
- Golden-file tested parsers. Each transaction-set parser ships with byte-identical golden files so a refactor that drifts the wire format trips a local CI failure rather than a partner rejection.
No extra activation. The gateway ships with
the platform and runs whenever a customer configures an
edi_transports row. SFTP-only today; AS2 adds
when a partner specifically requires it.