Skip to content 
A multimodal freight API is a connection that lets one system request, compare and book air, ocean and trucking options for a shipment through a single integration.
The hard part of a multimodal integration is not the connection. It is the data model. Air, ocean and truck freight are priced, loaded and documented on different units, so a shipment record that rates cleanly by truck can be useless for an air or LCL request. This guide is written for the people who design that record: what each mode needs, how to normalize the answers into one comparable list, and which industry standards are worth following. It complements the ExFreight freight API overview, which covers access and the available services.
Key takeaways
- Design one shipment object that holds the superset of fields air, ocean and truck rating need, then map it to each mode.
- Comparing modes means normalizing scope, transit and charge basis, not just sorting by price.
- Standards exist per mode (DCSA for container shipping, NMFTA’s DSDC for LTL and truckload, X12 for EDI), so plan for mappings rather than a single universal schema.
What a multimodal freight API is
A single-mode API answers one question: what does this truck, flight or container cost? A multimodal API answers a broader one: what are my options for moving this freight from here to there, across modes, and how do they compare? It accepts one shipment description, prices it in each mode that fits, and returns the options in a consistent structure so your software can rank them.
That is a different problem from the commercial case for multimodal choice. If you want the business view (why instant options across modes help shippers balance cost and speed), read how digital freight forwarders provide multi-modal shipping options. Here the focus is the engineering: the fields, the units and the comparisons.
Multimodal in this sense means modes chained door to door: a truck pickup, a main leg by air or ocean, and a truck delivery. Some providers also include rail. ExFreight’s quoting API covers domestic and international air, ocean and trucking, with rates and transit times included.
How one request maps to air, ocean, LTL and parcel
Start with the superset. The table shows which data each mode prices on and what it needs beyond origin, destination and date. Build your shipment object so it can satisfy each column, then send each mode only what it uses. Fields a mode ignores cost nothing to store; fields a mode needs and you lack cost a wrong price or a rejected booking.
| Mode | Pricing unit | Fields it depends on | Common trap |
|---|---|---|---|
| Air | Chargeable weight (greater of actual and volumetric) | Piece count, dimensions per piece, gross weight, commodity, stackability | Sending total weight without dimensions understates bulky freight. |
| Ocean LCL | Weight or measure (W/M) | Dimensions per piece, total cbm, gross weight, commodity, cargo-ready date | Rounding cbm per pallet instead of per shipment. |
| Ocean FCL | Per container | Container type and count, commodity, cargo weight, scope (door or port) | Ignoring road weight limits on the trucking legs. |
| LTL | Per hundredweight by class or density, with minimums | Handling units, dimensions, weight, class or density, accessorials, location type | Defaulting accessorials to none. |
| FTL | Per load | Equipment type, total weight, pickup and delivery windows | Treating a 10-pallet load as automatically LTL or automatically FTL. |
| Small parcel | Per package, often dimensional | Package count, dimensions, weight, declared value | Palletized freight does not belong in a parcel request. |
Worked example: one record, four answers
A machinery parts supplier in Chicago ships 6 non-stackable pallets to a customer near Rotterdam. Each pallet is 120 x 100 x 110 cm and 280 kg. One shipment object holds that data. Mapped by mode:
- Air: volumetric weight per pallet is 1,320,000 / 6,000 = 220 kg, below the 280 kg actual, so chargeable weight is 1,680 kg.
- Ocean LCL: 1.32 cbm per pallet, 7.92 cbm in total, against 1.68 metric tons. Billed on 7.92 W/M. Non-stackable status must travel with the request.
- Ocean FCL: six 120 x 100 cm pallets fit on the floor of a 20-ft container, so an FCL option is worth pricing against LCL.
- Trucking: the U.S. pickup leg to the port or airport is an LTL move: 6 handling units, dimensions converted to inches and pounds, dock pickup.
The same 6 pallets produce four valid requests with four different units of charge. A data model that stores only “weight: 1,680 kg” can serve none of them well.
The ExFreight platform also offers international small parcel shipping for B2B exports under 150 lbs that are not palletized; the small parcel service page lists its scope and limits. Keep a mode-eligibility rule in your code so palletized freight never reaches a parcel request. The freight API for e-commerce guide applies the same rule at checkout.
Comparing modes in one response
Once each mode returns options, your system has to put them on one list. Price alone misleads. Normalize these four dimensions first:
- Scope. A port-to-port ocean rate and a door-to-door air rate are not comparable. Convert or filter so all options share the same scope.
- Transit. Express transit in calendar days from cargo-ready date to delivery, not mode-native counts such as “port to port days” or “business days from pickup”.
- Charge basis. Show total landed freight cost and cost per kilogram or per unit, so a buyer can see why air costs more and by how much.
- Exclusions. Flag what each option leaves out, such as duties, taxes, bonds or accessorials, so a cheaper option is not cheaper only because it is less complete.
Estimated emissions can be a fifth column; the freight emissions calculation guide explains why figures from different providers rarely match.
The integration choice behind that list is whether to call one unified endpoint or several mode-specific ones.
| Unified multimodal endpoint | Separate mode-specific endpoints | |
|---|---|---|
| Build effort | One request format, one response format | One mapping per mode and often per provider |
| Cross-mode comparison | Options arrive in one structure | Your code merges and normalizes the results |
| Mode-specific detail | Depends on the provider’s schema depth | Full access to each mode’s fields |
| Maintenance | Changes managed by one provider | Each provider’s changes hit your code separately |
| Best fit | Shippers who choose modes per shipment | Shippers locked into one mode per lane |
For the price side of each mode, including surcharges and benchmark versus bookable data, see the freight rate API guide.
Standards that shape the data model
No single standard covers air, ocean and truck freight end to end, so multimodal integrations borrow from several. Knowing them helps you name fields in ways partners will recognize.
- Container shipping: the Digital Container Shipping Association publishes standards for booking, bill of lading, commercial schedules and track and trace, built with ten of the largest ocean carriers and aligned with ISO, IMO and UN/CEFACT.
- LTL and truckload: NMFTA’s Digital Standards Development Council maintains open API standards for motor freight, from quote to cash.
- EDI and files: ANSI X12 transaction sets and scheduled SFTP file transfers still carry much of the tendering, status and invoicing traffic between established partners, while interactive steps such as rating and booking suit on-demand API calls. The API vs EDI guide maps those sets to API calls and covers when to run both.
- Open quote and booking models: community efforts such as OpenFreight propose shared quote and booking schemas across carriers and forwarders. Useful as a reference for naming, even if your providers do not use it.
Operator tip: version your shipment object. When a mode adds a field (a new density requirement for LTL, a new data element for an ocean booking), add it to the superset with a default and a validation rule, then roll it into each mode mapping. Do not let one mode’s change break the others.
Pitfalls in multimodal builds
- Unit drift. Store dimensions and weight in one system of units and convert only at the request boundary.
- Silent defaults. A missing stackable flag or commodity description should block the request, not default to the cheapest assumption.
- Stale options. Air and ocean prices move. Keep the quote reference and expiry with each option and re-rate when it lapses.
- Booking mismatch. Book against the option that was rated. Changing pieces or dimensions between quote and booking invites re-invoicing.
Quotes are informational and subject to change. If the cargo tendered differs from the data in the request, the shipment can be re-invoiced to the actual details, in any mode.
What ExFreight’s API covers today
The APIs are available upon request, with a test environment and assistance. Connectivity gives access to ExFreight’s online rating, booking and tracking system. See how the ExFreight freight API works
Freight API series
Frequently asked questions
What are examples of multimodal transport?
A door-to-door ocean shipment is a common example: a truck picks up at the factory, a vessel carries the container between ports, and a truck delivers to the warehouse. Air export works the same way, with trucks feeding and clearing the flight. Some routings also combine rail, or ocean and air in one sea-air move.
Can one API compare air and ocean options for the same shipment?
Yes, if the request carries the data both modes need: piece count, dimensions, weight, stackability, commodity, and origin and destination with the service scope. The response should return each option with its price, transit time and quote reference, so your system compares like for like before booking. ExFreight's quoting API covers domestic and international air, ocean and trucking.
What is a multimodal freight API used for?
Shippers use a multimodal freight API to price one shipment across air, ocean and trucking, compare the options on cost and transit, and book the chosen one from their own TMS, ERP or order system. It replaces separate portal lookups per mode with one integration and a consistent response structure.
What data does a multimodal freight API need?
At minimum: origin and destination, cargo-ready date, piece count, dimensions and weight per piece, commodity, stackability and the service scope. Each mode then uses its own subset: chargeable weight for air, cubic meters for LCL, container type for FCL, and handling units, class or density and accessorials for LTL.
