How to Onboard a New Carrier Into Your TMS

Most TMS platforms can technically talk to most carriers. The problem is never whether the connection is possible, it's whether anyone validated it end to end before the first live shipment went out the door. Carrier onboarding TMS projects fail quietly: the commercial contract is signed, the carrier's documents are filed, and then three weeks later someone notices that tracking events never showed up for forty shipments. This guide walks through the actual technical steps of onboarding a new road carrier into your TMS, from choosing EDI or API to running your first test transaction and going live.

Why carrier onboarding breaks more often than it should

A carrier integration is supposed to move three things automatically: rate requests out, booking tenders out, and shipment status back in. A TMS carrier integration moves three things: rate requests out, booking tenders out and shipment status back in. When one of those three legs is missing, nobody notices immediately, because the shipment still moves, the driver still delivers, and the proof of delivery still gets signed. What breaks is the paper trail inside your TMS, and that's exactly the leg finance and customer service rely on.

This is a particularly European headache because your carrier base is rarely homogeneous. You're likely running DB Schenker or DSV on EDIFACT for FTL and groupage lanes, DPD, GLS or DHL Express on modern REST APIs for parcel volume, and a handful of regional hauliers who still take bookings by email or a web portal with no integration at all. Every one of those connection types has a different failure mode, and treating them the same way during onboarding is how shipments go dark.

What you need before you start

Before you touch the TMS configuration screen, get these in place. You'll need admin access to your TMS plus a sandbox or test environment that doesn't touch production data. You'll need a named technical contact at the carrier, not the commercial account manager, someone who can hand you AS2 certificates or an API key. And you need a decision already made on connectivity method, because that decision drives everything that follows.

EDI exchanges standardized messages, often in batches, the historic format of the transport industry, and remains relevant for very high volumes or partners already equipped. If you're adding a carrier that already runs IFTMIN and IFTSTA with other shippers, EDI is usually the path of least resistance. For API-first players, a serious forwarder provides documentation, a test sandbox, and support, so the setup stays measured on the IT side. Ask for that sandbox before you sign anything. If they can't produce one, that tells you something about how the integration will go.

You'll also need carrier master data ready: a carrier ID, GLN codes if you work with them, the service level codes the carrier uses internally, their accessorial list (ADR surcharge, lift-gate, pre-advice), and a rate card. Without the rate card loaded before go-live, you can't validate that the TMS is quoting the right price, which is where a lot of onboarding projects quietly go wrong months later at invoice time.

EDI vs API: what EU carriers actually offer

Note the contrast with US-style EDI: carriers that integrate by EDI exchange the X12 204 Motor Carrier Load Tender and 214 Transportation Carrier Shipment Status Message. European road carriers almost never run X12. If a vendor or consultant mentions 204/214 in a European context, ask them when they last worked on an EU account.

Step-by-step: connecting a new carrier to your TMS

1. Qualify the carrier's technical stack first. Ask directly: EDIFACT over AS2, REST/SOAP API, or web portal only. This single answer determines every step after it. Don't assume based on carrier size, some mid-sized regional hauliers run EDI because a bigger shipper forced the issue years ago.
2. Choose the connectivity method based on volume and existing infrastructure. If the carrier already has IFTMIN/IFTSTA running with another customer, EDI is usually faster to stand up than building a new API relationship. For parcel carriers like DPD, GLS or DHL Express, their APIs are built for this exact scenario and typically come with better documentation than their EDI offering.
3. Request test credentials before writing any mapping. For EDI, that's an AS2 certificate exchange and test ISA/GS envelope details so your first message doesn't bounce on a header mismatch. For API carriers, get a sandbox API key, the test endpoint URLs, and confirm how webhook subscriptions work, since without an API or EDI, every status, every cost, and every document is re-keyed by hand from one system to another, slow and error-prone; an API lets your ERP or TMS pull shipment data automatically.
4. Build the carrier profile in the TMS. Map the carrier's service codes, Incoterms handling, and accessorial categories (ADR surcharge, lift-gate, pre-advice) into one mapping table before you send a single test message. This is also where you add API or EDI credentials against the carrier record, not just a name and a contact email.
5. Configure the message flow in both directions. Outbound tender goes out as IFTMIN or an API shipment-create call. Inbound status comes back as IFTSTA or a tracking webhook. Proof of delivery arrives as DESADV or a dedicated POD endpoint. Map each of these separately, because a carrier can accept your tender perfectly and still never send status back.
6. Run end-to-end test transactions, not partial ones. Send a real test tender through the sandbox, confirm the carrier's system accepts or rejects it programmatically, and watch for a status event landing back inside your TMS. A human confirmation email from the carrier's ops team does not count as a passed test.
7. Validate rate and invoice matching before go-live. Upload the agreed price list and run a mock freight audit against test shipments. This matters because a connector that works can still produce a re-invoice: if the SKU dimension records in the TMS hold an outdated pallet height, every rate it requests is built on the wrong volume, and the carrier bills what it measures. Catching that in testing costs you nothing. Catching it after 200 live shipments costs you a dispute.
8. Pilot on one lane before opening full volume. Route a small, low-risk lane through the new connection for one to two weeks. Watch tender acceptance rates, status latency, and whether any shipments go quiet. Only then open the carrier up to full allocation.

How to know it worked

You're done when tenders go out and come back accepted or rejected without anyone writing an email. Status milestones, picked up, in transit, delivered, land in the TMS without manual re-keying. And when the first real invoice arrives, it matches your rate card within an agreed tolerance on the first pass, not after three rounds of back-and-forth with the carrier's billing team.

If any of those three checks fail, the integration isn't done, regardless of what the project plan says.

The most common failure mode and the fix

The pattern that catches shippers out most often: the carrier accepts tenders cleanly but never sends status events back. The shipment physically moves and gets delivered, but inside your TMS it sits in "tendered" status forever. Nobody notices until a customer calls asking where their order is and your team has no visibility beyond the original booking.

The fix is a monitoring rule, not a bigger integration project. Flag any shipment with no status update after a set number of hours, and route that flag to the carrier's EDI or API contact directly, not to their generic customer service line. The biggest variable is usually data cleanup and business rules, not the technical connection, and that holds true here too. The AS2 channel or the API webhook is usually fine. What's missing is someone on the carrier's side actually triggering the status message when the driver scans the delivery.

Where this fits in a wider multi-carrier strategy

Repeating this eight-step process for every carrier doesn't scale once you're running more than a handful of connections, which is why multi-carrier platforms exist. Carrier onboarding is faster when prebuilt connectors exist, often days for known carriers, versus typically weeks per carrier when certification is required from scratch. Platforms like Cargoson, MercuryGate, Alpega and Transporeon maintain pre-built connectors to the major European carriers, which means steps two through five above get skipped entirely for any carrier already in their network. One real case of what that saves: tools and machinery wholesaler Stokker needed to move ERP systems, and rather than rebuild every carrier integration in the new system, it connected all its transport partners through Cargoson, cut setup time from weeks to minutes, and now runs 15,000 shipments a month with a two-person team.

For carriers that aren't pre-built anywhere, the manual process above still applies. That's also true for the long tail of regional hauliers who only take bookings by email, where if a carrier does not have their own e-environment and accepts bookings via e-mail, that gets set up in the TMS too, so you can still book all your transports to all of your carriers through one account. The technical rigor is the same whether you build it yourself or a platform builds it for you. What changes is who absorbs the three to five days of mapping work the first time around.