Logistics software runs on integrations. A freight-tech company's backend might talk to a TMS for shipment tracking, a WMS for inventory and fulfillment, a freight broker API for rate quotes, a carrier tracking API for real-time status, and an ERP for invoice reconciliation — all within a single order lifecycle. Each of these systems has an API. Each API works slightly differently.
This guide is not a survey of every logistics API in existence. It's a map of the patterns that recur across them — the auth models, pagination strategies, and event schemas that you'll encounter regardless of which specific TMS, WMS, or freight API you're integrating. Understanding the patterns means you can evaluate a new connector in hours rather than days.
The API Landscape
Logistics software spans a wide maturity range. Modern cloud-native TMS and freight API providers (built post-2015) typically have REST APIs with OAuth2, cursor-based pagination, and webhook event delivery. Older enterprise WMS and ERP systems may expose SOAP/XML APIs, flat-file exports, or REST APIs bolted onto a legacy core — with API key auth, offset pagination, and polling instead of webhooks.
The maturity gap matters for integration planning. A modern TMS API integration might take a day with a typed SDK. An older WMS that exposes REST endpoints on top of a decade-old relational database might require understanding undocumented behavior — field lengths enforced at the database layer rather than the API layer, enum values that accept different strings depending on the record's age, pagination that breaks at exact multiples of the page size.
TMS APIs
Transportation Management System APIs are primarily used for shipment lifecycle events: creating shipments, getting carrier quotes, booking loads, and tracking status. The key data objects are shipments, loads, carriers, routes, and tracking events.
Auth is typically OAuth2 for user-delegated workflows (a shipper authorizing your app to manage their shipments) or API key for server-to-server integrations (your platform calling the TMS on behalf of your customer). Most modern TMS APIs support webhooks for status events — shipment created, pickup confirmed, in-transit, delivered. The webhook payload schema varies significantly between vendors; normalizing it is one of the most valuable things an SDK abstraction layer can do.
The common integration bug: assuming shipment status is a finite enum. It's not. Carrier status codes are mapped by the TMS to a normalized set of statuses, but the mapping is imperfect and TMS vendors add carrier-specific status codes without versioning. Your code that switches on status === 'in_transit' will behave incorrectly when a carrier returns a status that maps to something between departed_origin and in_transit in a TMS update.
WMS APIs
Warehouse Management System APIs are used for inventory reads, inbound receipt confirmations, and outbound fulfillment. Key objects: inventory items, locations, receipts, orders, and shipment confirmations.
WMS APIs are frequently the most challenging to integrate. The underlying data model is optimized for warehouse operations, not API consumers — fields have abbreviated names that make sense to warehouse staff but not to external developers, date fields are often stored as strings in non-ISO formats, and the "available" vs "reserved" vs "on-hand" distinction in inventory counting has different semantics across vendors.
Webhook support in WMS systems is inconsistent. Older systems require polling. When polling, pay attention to the "modified since" filter — many WMS APIs support ?modified_after=2024-01-01T00:00:00Z which dramatically reduces response sizes for incremental syncs. Without this filter, you're fetching the full inventory on every poll cycle.
Freight APIs
Freight broker and carrier APIs cover rate quoting, booking, and tracking. The rate quoting workflow is typically synchronous (POST a quote request, get rates back in the response). Booking is asynchronous — you POST a booking request and receive a confirmation webhook. Tracking is event-based via webhook or polling against a tracking ID.
The key friction point with freight APIs is data completeness requirements. Rate quote and booking requests have mandatory fields that vary by carrier and shipment type. Missing a required dimension (weight, freight class, hazmat flag) produces a 400 error with a message that may not clearly identify the offending field. Build your integration with strict input validation before sending to the carrier API.
Common Patterns Across All Three
Across TMS, WMS, and freight APIs, these patterns recur:
- Idempotency keys for write operations. Booking a shipment, confirming a receipt, creating an order — all of these have real-world consequences if executed twice. Pass an idempotency key on every write operation and verify the API honors it.
- Separate APIs for historical vs. operational data. Many logistics platforms have a high-frequency operational API (real-time status, current inventory) and a separate reporting or data export API (historical records, audit trails). The reporting API often uses different auth and different pagination.
- Schema versioning via header, not URL. Some logistics APIs version responses via
Accept-Versionheader rather than URL path. If you're pinned to a specific version, ensure your client sets this header on every request.
Using Devloom for Logistics Integrations
The Devloom connector catalog includes TMS connectors (Shipwell TMS in GA), WMS connectors (Palco WMS in GA), and freight connectors (Argent Freight in Beta). Each connector encodes the auth model, pagination strategy, webhook event schema, and rate limits for that specific system. The SDK applies the correct behavior automatically.
For logistics integrations not yet in the catalog, the SDK's dlx.client.raw() interface allows you to use Devloom's auth management and retry logic against any HTTP endpoint — so you get the infrastructure benefits even for connectors that haven't been formally cataloged.