EDI Integration for Logistics and Freight Carriers

Connecting carrier systems to your own TMS or logistics platform is where EDI integration for logistics starts. Without a working connection, a dispatcher keys shipment details into carrier portals by hand, copies tracking numbers between screens, and reconciles invoices in a spreadsheet. With it, booking, tracking, and invoice exchange run without manual entry.

Carrier integration usually follows two paths. Freight carriers that move LTL and FTL loads run mostly on EDI, a standard from the 1970s that is still widely required across established freight networks. Parcel carriers like FedEx, UPS, and DHL run mostly on modern REST APIs.

This article covers how to integrate both carrier types, which EDI transaction sets you need, and how major carriers are typically integrated in 2026. It is written for teams building or extending a custom transportation management system that has to book, track, and settle freight across many carriers.

What EDI is and why it still matters in 2026

EDI (Electronic Data Interchange) is a standardized format for exchanging business documents between trading partners without human typing, automating the back-and-forth that used to happen by phone, fax, and email. In logistics, load tenders, shipment statuses, and freight invoices move between a shipper or broker and a carrier as structured messages a machine can read.

EDI remains widely required in 2026 because most large US LTL and FTL carriers built their operational systems around it decades ago and still expect it, especially across established enterprise freight relationships. It sits inside carrier billing, dispatch, and status systems, and replacing that infrastructure is a slow industry-wide shift, so a shipper booking freight with a major carrier network usually has to support EDI to connect.

APIs are gaining ground alongside it. The NMFTA Digital LTL Council now publishes API standards for the LTL segment, including eBOL, pickup-request, and preliminary freight-charges APIs. Standardized freight APIs are becoming more common, but in freight EDI is still the connection most established relationships run on, and new integrations increasingly support both approaches. Parcel carriers have moved further, treating REST APIs as their primary method, covered below.

How an EDI file is structured

An EDI file is not a table or JSON. It is a plain-text file with a nested hierarchy, and knowing the levels makes the transaction sets below easier to read:

• Envelope — wraps the whole transmission between two trading partners.
  • Functional group — bundles documents of the same type.
    • Transaction — one business document, such as a single load tender.
      • Segments — the lines inside the document.
        • Elements — the fields inside a segment.
          • Components — sub-fields inside an element.

In logistics you meet two encodings of this structure. ANSI X12 is used in the US and North America and identifies documents by number (204, 214, 210). EDIFACT is used in Europe and most international trade and names its messages instead (IFTMIN for instructions, IFTSTA for status, INVOIC for invoices). The two also differ in syntax and delimiters, so a translator has to support whichever format a carrier or lane requires. X12 dominates US domestic freight, while EDIFACT dominates cross-border and ocean trade.

The transaction sets below use the X12 numbering.

Inside your TMS a shipment is a JSON object your code works with directly:

{
  "loadNumber": "LOAD12345",
  "billOfLadingNumber": "BOL789456",
  "paymentTerms": "Prepaid",
  "pickup": {
    "name": "ACME WAREHOUSE",
    "address": "100 INDUSTRIAL RD",
    "city": "CHICAGO",
    "state": "IL",
    "postalCode": "60601",
    "country": "US",
    "date": "2026-06-24",
    "time": "09:00"
  },
  "delivery": {
    "name": "CUSTOMER DC",
    "address": "500 MARKET ST",
    "city": "COLUMBUS",
    "state": "OH",
    "postalCode": "43004",
    "country": "US",
    "date": "2026-06-25",
    "time": "17:00"
  },
  "carrier": {
    "scac": "EXFC"
  },
  "freight": {
    "description": "PALLETIZED GOODS",
    "weightLb": 5000,
    "ladingQuantity": 10
  },
  "specialInstructions": [
    "LIFTGATE REQUIRED AT DELIVERY"
  ]
}

The EDI mapper flattens those nested fields into segments, where each segment is a line ending in ~ and each * separates an element, and the full load becomes an X12 204 load tender, walked through in the next section. Writing and maintaining this field-by-field mapping for every carrier is the bulk of an EDI integration.

EDI transaction sets used in carrier integration

The EDI transaction sets logistics teams rely on cluster around the freight booking cycle, from offering a load to settling the invoice.

• EDI 204 (Motor Carrier Load Tender). A shipper or broker offers a load to a carrier: pickup and delivery addresses, weight, dimensions, requested dates, and special instructions. The carrier accepts or declines, replacing the email or phone call that used to start the booking.
• EDI 990 (Response to Load Tender). The carrier answers the 204 with acceptance or rejection, so the TMS knows whether the load is booked.
• EDI 214 (Transportation Carrier Shipment Status Message). The carrier pushes status events: pickup, in-transit milestones, delivery, and exceptions. It feeds automated shipment-status updates into your TMS without anyone logging into a carrier portal.
• EDI 210 (Motor Carrier Freight Details and Invoice). The carrier sends its invoice. Pairing the 210 against the quoted rate enables automated freight audit, catching overbilling before payment.
• EDI 997 / 999 (Functional and Implementation Acknowledgment). Reports the result of syntax and implementation-level validation. An acknowledgment may accept, accept with errors, or reject a transaction. It does not confirm business acceptance or successful processing inside the receiving TMS.

Beyond that core, a few sets show up by use case. The 856 (Ship Notice/Manifest, ASN) carries shipment contents ahead of arrival and drives warehouse receiving in a WMS. The 810 is a general invoice used across parcel and freight billing. The 850/855 (Purchase Order and PO Acknowledgment) are order-level messages for trading-partner integration where the order itself crosses the wire, not only the shipment.

Inside an EDI 204 load tender

The 204 is the load tender you send a carrier. It carries the sender and receiver, load and bill-of-lading numbers, carrier SCAC, pickup and delivery addresses with dates and times, freight description, weight, and special instructions. The example below shows ACME tendering load LOAD12345 to an LTL carrier with SCAC EXFC, picking up a shipment with a lading quantity of 10 from Chicago on 2026-06-24 and delivering to Columbus on 2026-06-25. As an X12 204 that reads approximately:

ST*204*0001~
B2**EXFC**LOAD12345**PP~
B2A*00~
L11*BOL789456*BM~
G62*77*20260624*2*0900~
G62*78*20260625*3*1700~
N1*SF*ACME WAREHOUSE~
N3*100 INDUSTRIAL RD~
N4*CHICAGO*IL*60601*US~
N1*CN*CUSTOMER DC~
N3*500 MARKET ST~
N4*COLUMBUS*OH*43004*US~
L5*1*PALLETIZED GOODS~
AT8*G*L*5000*10~
K1*LIFTGATE REQUIRED AT DELIVERY~
SE*16*0001~

B2 carries the carrier SCAC and the PP prepaid term, L11 the bill-of-lading number, the two G62 segments the pickup and delivery times, N1*SF and N1*CN the ship-from and consignee, AT8 the weight and quantity values, and K1 the special instruction. This is an illustrative fragment, not a complete carrier-certified 204. Production files usually include interchange envelopes, stop loops, and additional carrier-specific fields, and the exact segment qualifiers and values depend on the trading partner's X12 implementation guide.

A common core set for a shipper or broker that tenders freight is 204, 990, 214, 210, and 997 or 999. The exact transaction set depends on the party's role, carrier requirements, and operational workflow. A tracking-only integration may not use the 204 or 990 at all, while warehouse-heavy operations add the 856 and billing integrations add the 810. A 3PL running freight management for multiple clients usually needs the full freight set plus order-level messages per client program.

EDI vs REST API: when to use each

The split between EDI and API runs by message type. Time-sensitive events like dock appointments and GPS pings suit API speed, while EDI remains well suited to structured documents such as invoices and customs forms. The EDI vs API logistics choice is which protocol carries which message, not one or the other. REST APIs fit on-demand calls such as rating, label generation, and shipment lookup, and webhooks can push shipment-status events to your endpoint where the carrier and selected service support them. EDI is not always batch-only, since messages sent over AS2 can be delivered immediately too.

Use EDI when you integrate with US LTL and FTL freight carriers, since most require it. It also fits established B2B trading-partner relationships and enterprise supply chains whose downstream systems already depend on EDI.

Use REST API when you connect to parcel carriers. For standard parcel and express services, FedEx, UPS, and DHL treat REST APIs as the primary method for rating, labels, tracking, and pickup scheduling; a UPS API integration relies on UPS's own comparable REST suite for rating, shipping, and tracking. EDI appears with these carriers mainly in enterprise B2B freight such as the 856 ASN and 810 invoice, not standard parcel. To print a label and track a parcel, use the FedEx API integration or the DHL API, not an EDI mapping. REST also fits modern freight platforms and digital brokers, and any case needing a live rate quote or a label printed at shipment time.

For most logistics platforms, carrier networks span both worlds. EDI handles the LTL/FTL freight carriers, while each carrier API integration handles parcel and digital carriers. A platform that books against both usually needs an integration layer that speaks EDI and REST, because no single protocol covers a mixed carrier network.

What you need technically for EDI integration

EDI integration needs a specific stack on top of your TMS.

The EDI side: translator, transport, and certification

EDI translator/mapper. EDI documents use a rigid format, X12 in North America and EDIFACT internationally, and a translator converts between that format and the data structures your TMS works with. This segment-to-field mapping is where most of the project time goes.

Direction depends on which side of the relationship your platform sits on, so the same transaction set can be inbound or outbound. For a shipper or broker TMS that tenders freight, the split usually looks like this:

• Send (outbound): 204 load tender to the carrier, plus a 997 or 999 acknowledgment for each document received
• Receive (inbound): 990 tender response, 214 shipment status, 210 freight invoice

A platform that only tracks carriers and audits invoices, without tendering loads itself, drops the outbound 204 and becomes read-heavy. It ingests the 214 and 210, and returns a 997 or 999 reporting the validation result. Whether you tender loads or only consume carrier documents is the biggest driver of how much mapping a logistics EDI integration takes.

Communication method. Three options move the files:

• VAN (Value Added Network). A third party that runs EDI mailboxes and routes messages between trading partners. It simplifies onboarding each new carrier but charges a recurring fee, worth it when you maintain many connections.
• AS2 (Applicability Statement 2). Direct, secure transmission over the internet with no intermediary. Lower ongoing cost, but you configure it separately with each partner.
• SFTP. File-based transfer. Simpler to stand up, but less real-time than the alternatives.

Trading partner agreements. Every carrier ships its own EDI specification and onboarding process. You agree on which transaction sets, which X12 version, and which test procedure apply before anything goes live.

Testing environment. EDI carriers usually require certification testing first. You exchange test transactions, flagged with T in the ISA15 usage indicator so the carrier treats them as test rather than live orders, until it confirms your mapping is correct. Production interchanges normally use P, subject to the trading partner's implementation guide.

Error handling and monitoring. Rejected transactions, mapping errors, and missing expected 997 or 999 acknowledgments all surface here. A silent EDI failure can cause operational problems that surface days later, so alerting on these failures is part of the build, not an afterthought.

How an inbound EDI file is processed

An inbound EDI file runs through a fixed sequence before it reaches your domain model. The order matters. Storing the raw file and detecting duplicates early is what stops a re-sent file from booking the same load twice.

1. Receive the file over AS2, SFTP, or the VAN.
2. Store the raw file before anything parses it, so it can be re-read, deduplicated, and audited later.
3. Detect the partner from the ISA and GS sender IDs in the envelope.
4. Detect the document type (204, 214, 210, and so on).
5. Parse the EDI into objects with the translator.
6. Validate syntax against the X12 or EDIFACT structure.
7. Run partner-specific validation for the carrier's required segments and custom codes.
8. Map to a normalized DTO (data transfer object, a carrier-agnostic shape your code works with regardless of which partner sent the file).
9. Run business validation, checking a known load number, a valid SCAC, and sane dates.
10. Apply to the domain model, booking the load, updating its status, or posting the invoice.
11. Write the audit log, linking the raw file, the parsed result, and the action taken.
12. Send the acknowledgment (997 or 999) when the partner requires one.

Steps 6 through 9 are four distinct gates, not one. A file can be valid X12, pass the carrier's segment rules, and still fail business validation because the load number does not exist in your system. Collapsing them into a single check is how bad data reaches the domain model.

At step 8, map the parsed file into your own domain model, not into database tables that mirror EDI segments. EDI structure is carrier- and version-specific, so persisting it directly couples your schema to every carrier quirk and X12 version, and a new partner or a 4010-to-5010 upgrade then forces a database migration instead of a translator change. A normalized model keeps the wire format isolated in the translator, where it belongs.

The REST API side: parcel carriers

Parcel carrier APIs need a different set of plumbing, starting with authentication, which varies by carrier. UPS and FedEx use OAuth-based authentication. The integration stores client credentials and refreshes the access token before it expires, instead of logging in on every request. Some DHL APIs use Basic Authentication or another credential-based mechanism, and the exact flow depends on the specific API, region, and carrier program. Rate limits cap how many rating or tracking calls you can fire per second, so the client needs request throttling and a retry-with-backoff path for rejected calls.

For tracking, use carrier webhooks where the selected service, region, and account support them, since a webhook pushes each status event to your endpoint as it happens. Availability varies by carrier, specific API, region, customer account, and service or subscription plan, so where webhooks are not offered, fall back to rate-aware polling with adaptive intervals instead of a fixed timer. A team that has built a custom TMS before will recognize that the EDI and API sides need separate code paths inside the same platform, even when they end up writing to the same shipment record.

Onboarding a new carrier

Each carrier connection follows the same arc. An EDI carrier means agreeing the transaction sets and X12 version, building the mapping, passing certification testing, then monitoring acknowledgments once live. A parcel API means registering for credentials and integrating against the sandbox before production opens; FedEx issues OAuth client credentials through its developer portal, while DHL Express requires an active customer account and API access through the DHL Developer Portal. The exact credentials and authentication method depend on the selected MyDHL API variant.

What EDI carrier integration costs in 2026

EDI integration usually combines initial implementation costs with recurring platform, connectivity, monitoring, and support expenses, and it scales with carrier count and document volume. A logistics EDI integration has a few typical cost components:

• EDI platform or VAN fees. Recurring charges for the mailbox and message routing, scaling with document volume.
• Trading partner onboarding. Per-carrier setup to establish and agree each connection.
• Mapping and certification. Building each carrier's segment mapping and passing its certification testing.
• Custom integration development. The work to connect the EDI flow to your TMS, ERP, or WMS, plus the orchestration, validation, and monitoring around it.
• Monitoring and ongoing support. Alerting, error handling, and the map updates every carrier spec change forces.

Actual pricing depends on partner count, document types, traffic volume, and certification requirements, so treat any published number as a starting reference rather than a quote. Published vendor examples, such as BOLD VAN's 2026 pricing, range from a few hundred to several thousand dollars per month for the VAN, with separate onboarding, mapping-update, and certificate-renewal costs. These figures are illustrative, not industry averages. AS2 trades the recurring VAN fee for in-house setup and per-partner certificate management, which is why operations with many carriers often keep a VAN despite the cost.

Common EDI integration challenges

EDI is standardized on paper. The gaps between carriers are where a freight EDI integration slows down.

• Carrier-specific mappings. Two carriers can both send a "standard" EDI 214 and still differ in required segments, custom codes, and version details, and each keeps updating its spec, adding fields, and changing codes. Every difference and every change forces a mapping update and another round of testing. The spec is a baseline, not a guarantee of identical messages.
• Onboarding and certification. Trading-partner setup, mapping, and certification testing stretch a single carrier onboarding into weeks. EDI onboarding usually takes longer than integrating a well-documented parcel API because it adds partner-specific mapping and certification. Weak or missing carrier sandboxes make that testing harder than it should be.
• X12 version mismatches. Carriers sit on different X12 versions, 4010, 5010, and others, so the translator has to support several at once.
• Acknowledgment tracking across layers. EDI confirms delivery and validation at more than one level, and missing any layer hides a different failure:
  • The AS2 MDN (Message Disposition Notification) confirms the transmission was delivered.
  • The TA1 confirms the interchange envelope was syntactically valid.
  • The 997 or 999 reports whether the functional group or transaction passed syntax and implementation checks.
  • The 990 confirms the carrier accepted or rejected the load tender.

Syntax validation is not business acceptance, so a file can pass its MDN and 997 and still be declined by the 990. Matching each acknowledgment back to its document relies on the control numbers (ISA13, GS06, ST02), which must stay unique. A missing acknowledgment means a load tender or status update vanished silently, and nobody notices until a shipment is late.

• Duplicates and idempotency. The same EDI file can arrive more than once, through a retry after a timeout, a partner re-send, or a manual re-upload. Deduplicate on a stable key such as the interchange control number (ISA13), or the platform books the same load twice or pays the same 210 invoice twice. Store the raw inbound and outbound files alongside the parsed record, so you can re-parse after a mapping fix and prove what a carrier actually sent in a billing dispute.
• Monitoring and partial failures. One interchange can carry many transactions, such as a nightly batch of 50 EDI 214 status updates. A 997 or 999 can report acceptance, rejection, or partial acceptance at the functional-group and transaction-set levels. One malformed transaction should not require the other valid transactions in the interchange to be discarded. Status events add another trap. A carrier sends several 214s per shipment, and they do not always arrive in order. Apply each status by the event timestamp inside the 214, not the time the file landed, or a late "in transit" overwrites a "delivered." A silent EDI failure can cause operational problems that surface days later, so alerting on these failures is part of the build.

Build vs buy for logistics EDI integration

How much of the stack you run yourself is the next decision. Four approaches cover most freight EDI integrations:

Custom development does not usually mean writing an EDI translator from scratch. A common approach is to build orchestration, validation, mapping, and monitoring on top of an existing VAN or managed EDI platform.

How TwinCore builds carrier integrations

TwinCore builds custom EDI and REST API integration layers as part of custom TMS and logistics platform development. The integration is engineered for each client's carrier network, not sold as a packaged EDI product. On the EDI side, the team has connected US LTL and FTL carriers across the 204, 990, 214, 210, and 997 transaction sets; on the API side, it has integrated FedEx, UPS, and DHL for rating, label generation, and tracking.

That work connects EDI flows to existing TMS, ERP, and WMS platforms and implements carrier-specific mappings, validation, acknowledgment handling, and monitoring. The stack is .NET with REST API integrations on Azure or AWS, running on top of an existing VAN or managed EDI provider where one is already in place. The final architecture depends on the client's carrier network and workflows. TwinCore has been on the market since 2011, with 30+ specialists and 100+ delivered projects, including more than ten logistics builds.

Conclusion

Carrier networks that combine LTL/FTL freight with parcel and express services usually require both EDI and REST API integrations. EDI handles the LTL/FTL freight side, where many carriers still require it, while REST APIs handle parcel and express carriers like FedEx, UPS, and DHL. A sound architecture runs both protocols, absorbs carrier-specific variations, and monitors for the silent failures EDI is prone to. Every new carrier adds another mapping or API client to build and maintain, so carrier integration is ongoing work, not a one-time project.

Need to connect your platform with carriers? Talk to TwinCore.