Skip to content 
A freight API integration is the project of connecting your ERP, TMS, WMS or e-commerce system to a provider’s freight API so quotes, bookings and tracking flow without re-keying.
The connection itself is rarely the hard part. Projects slip on scope that was never written down, units that do not match, accessorials nobody mapped and tests run on demo lanes instead of real ones. This checklist covers the work from scoping to go-live, the questions to put to any freight API provider, and the pitfalls that show up after launch. For what the ExFreight API is and what it returns, start with the ExFreight freight API overview.
Key takeaways
- Scope before code: name the trigger system, the modes and lanes, and which of quote, book and track you need on day one.
- Most failed go-lives are mapping failures (units, location type, accessorials, postal codes), not connectivity failures.
- Ask a provider for a test environment, written field definitions and a named contact before you commit developer time.
Before you start: scope and modes
Write a one-page scope before anyone opens an editor. It should answer five questions:
- Which system triggers the call? An e-commerce cart quoting at checkout, an OMS booking when an order is packed, a TMS rate-shopping for a planner, or an ERP releasing orders. The trigger decides the volume and the response time you need.
- Which modes and lanes? Domestic LTL and FTL, international air, ocean FCL and LCL. List your top lanes by shipment count; they become your test set.
- Which functions on day one? Quoting alone is a smaller project than quote, book and track. Many teams launch quoting first and add booking once rates are trusted.
- Who selects the option? A routing rule (lowest cost within a transit window) or a person. Rules need cleaner data.
- Where do results land? Name the record that stores the quote, the booking reference and the status, and the people who read them.
Common trigger patterns: a cart calls the quote API and shows the freight cost before payment; an OMS calls booking when an order is marked ready; a TMS calls quote for rate shopping and booking for the tender; an ERP posts the quoted amount as a freight accrual. The TMS and ERP patterns have their own guides: TMS carrier integration and ERP freight integration.
Freight API integration checklist
- Name an owner on each side. One person in operations who knows the freight, one developer or integrator, and a contact at the provider.
- Request access and a test environment. Get test credentials, written field definitions and sample responses. ExFreight’s APIs are available upon request, with a test environment and assistance.
- Map the fields. Match each source field to the request field, including units and allowed values (see the next section).
- Build the quote call. Store the full response with a timestamp, not just the lowest price. You will need it when an invoice differs.
- Build booking from a stored quote. Book against the option the user or rule selected, then write the booking reference back to the order.
- Build tracking. Decide which status updates matter to whom, how often you check for updates, and where they display.
- Test on real history. Replay 20 to 30 shipments you already moved, with their real weights, dims and accessorials, and compare results with what you paid.
- Run in parallel, then cut over. Two weeks of quoting both ways, then go live on a subset of lanes before the rest.
- Monitor after launch. Track error rates, response times and quote-to-invoice variance weekly for the first quarter.
Field mapping and units
Field mapping is where integrations quietly fail. The call succeeds, a price comes back, and the error surfaces three weeks later on an invoice. Confirm the unit convention and field formats in the test environment, then map these with care:
| Field | Example | What goes wrong |
|---|---|---|
| postal code | 02101 (Boston) | Stored as a number, it loses the leading zero and becomes 2101, an invalid ZIP. |
| country | US, DE, CN | Typed country names (“USA”, “Deutschland”) fail validation. Use ISO two-letter codes. |
| weight | 410 kg = 904 lb | Sending kilograms where pounds are expected cuts the weight by more than half. |
| dimensions | 120 x 100 x 150 cm = 47.2 x 39.4 x 59.1 in | Rounding down each side overstates density and lowers the quote. |
| freight class | Class from the NMFC description | An outdated class in the item master produces a quote the carrier will correct. |
| location type | Business dock vs residential | Residential delivery is an accessorial; a wrong flag means a re-invoice. |
| accessorials | Liftgate, inside delivery, appointment | Internal codes that do not map to the provider’s list are silently dropped. |
| dates and times | Ready Tuesday, 4:00 PM ET | Server time in UTC versus dock time in ET shifts the ready date by a day. |
Worked example: a pallet from a European supplier is recorded in the ERP at 120 x 100 x 150 cm and 410 kg. Converted, that is 47.2 x 39.4 x 59.1 inches and 904 lb, or about 63.6 cubic feet and 14.2 lb per cubic foot. If the integration rounds to 47 x 39 x 59 inches, volume drops to 62.6 cubic feet. Small on one pallet, consistent across thousands. Round up, never down, and send the class that matches the NMFC description; the NMFC freight class guide explains how class is assigned. The full list of quote request fields is in the freight quote API guide.
Testing in a sandbox
A test environment proves the connection works. Your test plan proves the business logic works. Build a matrix that covers:
- Happy paths per mode. One domestic LTL lane, one FTL lane, one international air lane, one ocean LCL lane and one FCL lane, if you ship them.
- Accessorial cases. Liftgate, residential, appointment, inside delivery. Confirm each one changes the rate.
- Bad data. Missing dims, zero weight, invalid postal code, unknown country. The provider should reject them; your system should show a clear message instead of a blank price.
- Timeouts and fallback. Decide what the user sees if no response arrives in a few seconds. A “request a quote” path is safer than a cached price shown as bookable.
- Booking changes. Book, change and cancel a test shipment, and confirm your records follow each step.
Industry groups are working to standardize these exchanges. The NMFTA Digital Standards Development Council publishes API standards for LTL and FTL, which help when you compare how providers name and structure fields.
Quotes returned by a freight API are informational and subject to change; shipments can be re-invoiced if actual details differ from the request, such as weight, dimensions, location type or accessorials. On U.S. imports, a basic customs entry is included in door-to-door rates; duties, taxes, bonds, MPF and HMF are billed separately.
Questions to ask a freight API provider
Put these to any freight API provider before committing developer time. Written answers make the comparison easy.
- Which modes and lanes return rates through the API, and which require a manual quote?
- What do quote responses include: transit time, carrier options, accessorials, ports?
- Is there a test environment, and who answers integration questions while you build?
- How do booking changes and cancellations work after confirmation?
- How are tracking updates delivered, and how often should your system check for them?
- Where do documents and invoices live: in the API, in a portal or by email? The bill of lading API guide covers the document side.
- What happens when actual weight, dims or accessorials differ from the quote?
- Which TMS platforms already connect, so you can skip custom work?
The other choice is structural: one provider that covers several modes or a separate integration per carrier.
| Multimodal forwarder API | Direct carrier APIs | |
|---|---|---|
| Integrations to build | One connection for several modes and lanes | One per carrier, each with its own fields and rules |
| Modes | Air, ocean and trucking in one schema | Usually the carrier’s own mode only |
| International work | Forwarder coordinates door-to-door moves and filings | You coordinate pickup, port and delivery legs |
| Rate comparison | Options returned side by side | You compare across separate responses |
| Maintenance | One set of field changes to track | Changes multiply with the number of carriers |
For ExFreight, the answers are short. Quoting covers domestic and international air, ocean and trucking, with rates and transit times. Booking covers all booking activity, updates, changes and confirmations. Tracking covers location-based digital tracking and manual updates. Documents, invoices and the duty and tax calculator sit on the ExFreight platform, and existing TMS integrations cover nine platforms. How the integration differs from a file-based EDI setup is covered in API vs EDI for freight.
What ExFreight’s API covers today
APIs are available upon request, with a test environment and assistance. Connectivity gives access to ExFreight’s online rating, booking and tracking system, and existing TMS integrations cover Project 44, Accufrate, Banyan, SAAS, 7L, Primus, Pacejet, CSA Software and Teknowlogi. See how the ExFreight freight API works
Freight API series
Frequently asked questions
What is API integration in logistics?
API integration in logistics connects a shipper's systems, such as an ERP, TMS, WMS or e-commerce platform, to carriers and forwarders through programmatic calls. The shipper's system sends shipment details and receives quotes, booking confirmations and tracking updates automatically, which removes portal logins, re-keying and the errors that come with copying data by hand.
What are the 5 stages of API integration?
A practical way to divide the work is five stages: scope (trigger system, modes, functions), access (credentials and a test environment), build (field mapping and the quote, booking and tracking calls), test (real historical shipments, edge cases, fallbacks), and launch with monitoring of errors, response times and quote-to-invoice variance.
Is an API just a JSON?
No. An API is the interface: the endpoints, the rules for what a request must contain and what the response returns, and how access is granted. JSON is one common data format used to carry those requests and responses; XML is another. Ask each freight provider which format, fields and authentication method its API uses.
What is the most widely used API?
By style, web APIs that follow REST conventions over HTTP are the most common pattern across industries. In freight, the most frequently called function is usually the rate or quote request, because shippers and checkout pages quote far more shipments than they book. Booking and tracking calls follow once an option is selected.
