API vs EDI vs Rate Grid: Carrier Integration Compared

The three methods are usually presented as a ladder — API best, EDI acceptable, spreadsheet last. That framing is wrong, and it costs brokers money, because the three do not do the same job. What separates them is what travels and who has to build something.

Read the third column again. With an API or EDI, the carrier has to have already invested in the connection before you can use it, so your carrier list is limited by other companies’ IT budgets. With a rate grid, the tariff PDF or Excel file already sitting in your inbox is the integration surface, and the work is entirely yours to schedule.

The methods are also not mutually exclusive, and a broker running all three is normal: a rating API on the two parcel networks, EDI with the one shipper that demands it, and grids for everything else. What decides the order is coverage. Integrating in the API-first order leaves part of your panel un-quotable for as long as the first connector takes; integrating in the grid-first order makes the whole panel quotable, then adds connectors where volume justifies them.

Cargavo, a TMS for freight brokers and transport commissionaires of 2 to 25 people, only implements the third method. That is a scope decision, not an omission, and the rest of this guide explains the reasoning honestly — including the cases where it is the wrong answer. For the wider onboarding context, see the carrier onboarding category and the pillar on carrier integration for freight brokers.

Vendors say "we integrate with carriers" as if a carrier exposed a single door. In practice you are dealing with distinct services, and a carrier can offer one without the others:

• Rating — you post an origin, a destination and a shipment, you get a price back. This is the one that matters for quoting.
• Booking and documents — you post a confirmed shipment, you get a consignment number, a label and a CMR.
• Tracking — you poll a reference, you get a status and a proof of delivery.

Parcel and express networks price by account number, weight and dimensions, and their rating endpoints are genuinely useful because the price really can change per shipment. Palletised groupage and part-load carriers are a different animal: your price is a tariff you negotiated for the year, and in most cases the carrier back office holds it as a customer-specific table — the same table it emailed you in January. A rating call, when it exists, returns that stored tariff. You are paying an integration cost to be told a number you already own.

Three operational costs are routinely underestimated. Versioning: when the carrier ships v3 and sunsets v2, the deadline is theirs, not yours. Latency: a multi-carrier comparison is only as fast as the slowest endpoint, so you need timeouts and a fallback price, which means you need a stored tariff anyway. Opacity: an API answers one shipment at a time, so you cannot sweep it to check that every bracket from 100 kg to 3,000 kg on a lane looks sane. A stored grid is inspectable; an endpoint is a black box that you can only interrogate one call at a time.

None of that makes APIs bad. It makes them a tool for the flows where the price is genuinely dynamic — which, for a road freight broker quoting negotiated tariffs, is the minority of the panel. See quoting regional carriers that have no API.

This is the most misunderstood point in carrier integration, so state it flatly: EDI is downstream of pricing, not a source of it. Look at what the standard message sets actually carry.

A 204 tender or an IFTMIN instruction can carry a rate, but it is a rate you decided before sending the message. A 210 or an INVOIC tells you what the carrier billed, which is useful for reconciliation and useless for quoting, because it arrives weeks after you committed to a sell price. There is no EDI equivalent of "what would this shipment cost?".

The second thing to know is that EDI is a per-partner project. Each connection needs a transport agreement (AS2 certificates, an SFTP drop or a VAN mailbox), a segment-level mapping of your data onto their implementation guide, a test cycle where both sides certify sample messages, and a named person on each side when a mapping breaks. Two carriers using the same standard will still have different qualifiers, different reference segments and different mandatory fields.

Where EDI genuinely earns its cost is a high-volume contractual flow that runs every day with the same partner — and, very often, it is your customer, not your carrier, who requires it. A large shipper that mandates 204 and 214 messages is imposing EDI on you as their supplier. That is a real requirement, and it has nothing to do with how you price. You still need a tariff somewhere to know what to charge: see carrier rate grid management.

The freshness objection sounds decisive until you ask how often the underlying number actually moves. A groupage or part-load contract states a validity period, and inside that period the carrier is bound by it. Quoting from a grid dated within its validity window is quoting the contract, which is exactly what the carrier will invoice.

What moves monthly is the fuel surcharge, and it is indexed, not negotiated. Take a complete example on one lane.

Carrier tariff valid 1 January 2026 to 31 December 2026. Grid type weight_zone, zone 2, bracket 1,000–1,999 kg at €14.80 per 100 kg. Shipment: 1,240 kg.

• Base buy price: 12.40 × €14.80 = €183.52. The engine also tests the next bracket floor — 2,000 kg at €12.30 per 100 kg = €246.00, which is worse, so €183.52 stands.
• Fuel surcharge, February: index €1.61 per litre against a base peg of €1.40, fuel weighted at 30% of the cost base. (1.61 − 1.40) ÷ 1.40 × 0.30 = 4.5%. Buy price becomes €191.78.
• Sell price at an 18% margin using p/(1−m): €191.78 ÷ 0.82 = €233.88. Margin earned: €42.10.
• March: the index moves to €1.68. (1.68 − 1.40) ÷ 1.40 × 0.30 = 6.0%. Buy price €194.53, sell price €194.53 ÷ 0.82 = €237.23.

Between February and March the sell price moved by €3.35. The grid did not change, no integration was involved, and the only input that changed was one published index figure. That is the honest shape of rate freshness in contracted road freight: a stable table plus an indexed coefficient.

The real staleness risk is not technical, it is administrative — quoting from a tariff whose validity date has passed because nobody logged the new one. That is a process problem an API does not fix either, and it is why validity dates belong on every grid. The carrier onboarding checklist covers what to capture at rebuild; the four grid types covers which shape your tariff takes.

Coverage is the argument that decides the question for a small brokerage, and it is easiest to see on a constructed example. Take a panel of 14 carriers of the kind a mid-sized road broker typically runs, and ask what each one can offer.

This is an illustrative panel, not a market statistic — but rebuild it with your own carrier list and the shape will not surprise you. The two columns that matter are the first and the last: an API-first strategy makes 2 carriers quotable immediately and leaves 12 lanes priced by hand for months, while a grid-first strategy makes all 14 quotable in the order you choose to do the work.

The distribution is not accidental. A rating API is worth building for a carrier whose price varies per shipment across thousands of accounts. A 25-truck part-load haulier has dispatchers rather than developers, sells an annual tariff that does not move during the day, and would be spending money to publish numbers it has already emailed you. It will never build one, and that is a rational decision on its part.

It also matters commercially, because the long tail is often where the margin is: the regional haulier that is cheapest on its home lane is quoted by fewer competitors than the national network everyone can reach. Cargavo, a TMS for freight brokers, treats that tail as the default case rather than the exception — see comparing several carriers on the same lane.

Say the limits plainly, so you can decide against us if they disqualify us. Cargavo has no carrier API connectivity and no EDI connectivity. It is also not a freight exchange or load board, not a fleet management or dispatch system, not a tendering marketplace, and not an accounting package.

What that costs you: no live parcel rating that varies by the hour, no automated tracking feed pulled from carrier systems, no automatic tender of a load into a carrier TMS, and no EDI invoice reconciliation. If those are your daily bottleneck, a connectivity-first platform is the right purchase and this is the wrong product.

What you get instead is that every carrier on your list is quotable under the same rules on day one. A carrier is onboarded by entering its existing Excel or CSV tariff as one of four grid models — weight_zone (zones × weight brackets), pallet (price by pallet count × zone), mpl_bracket (linear-metre / LDM brackets × zone) and hybrid_weight (a flat rate below a threshold, a per-unit rate above it). One engine reads all four, and the same engine produces the buy price and the sell price: buy without margins, sell with them, applied server-side per customer, per grid or per bracket, as a percentage using p/(1−m) or as an absolute amount.

Two consequences follow that connectivity does not give you. First, the customer never sees a buy rate or a margin, because those live server-side and are never sent to the portal. Second, an accepted quote (Q-YYYY-NNNN) becomes a tracked shipment (S-YYYY-NNNN) as one continuous record, in English, French, Spanish or German on every plan, and priced in EUR, USD, GBP, CHF, CAD, MAD or PLN from the Growth plan.

Grid integration is included in every plan: Starter €49/month, Growth €149/month, Scale €399/month, annual billing worth about two months free, with a 14-day free trial and no credit card. Full limits on the pricing page; the practical procedure is in onboarding a carrier without an API.

Integration decisions get made on instinct and defended with adjectives. Do the division instead. Suppose a rating connector for one carrier costs you €4,000 of developer time plus ongoing maintenance, and it lets you win a flow you currently decline, at the €42.10 margin per shipment computed earlier. Break-even is €4,000 ÷ €42.10 ≈ 95 shipments. At 2 shipments a week, that is about 48 weeks before the connector has paid for itself — and the maintenance clock never stops.

Run the same division for a connector that saves time rather than winning revenue, and be honest about the input: the saving is the minutes removed from work you actually do today, not the theoretical maximum.

Four situations genuinely justify the project:

• Parcel and express volume, where the price legitimately varies per shipment by dimension and account, and a stored tariff cannot reproduce it.
• A customer mandate — a large shipper that requires 204 and 214 messages, or their EDIFACT equivalents, as a condition of the contract. Non-negotiable, and unrelated to how you price.
• One dominant carrier carrying a large share of your daily consignments, where automated tendering and status updates remove a real person-day per week.
• Invoice reconciliation at volume, where matching hundreds of monthly invoices to expected buy prices by hand has become its own job.

What does not justify it: the belief that an API returns a fresher price than your contract, or a procurement checklist that scores "number of integrations" instead of "share of your panel you can quote today". A broker who starts with grids covers the whole panel first and can still add a connector later where one of the four cases above applies. Starting API-first leaves most of the panel un-quotable while the first connector is being built.

The order is the whole point: cover the panel, then optimise the flows that earn it. Practical next step in the carrier onboarding checklist.