Freight Tracking API: Ltl and Freight Data, Integration Steps, and Coverage Limits

A freight tracking API connects shipment updates from carriers, forwarders, or visibility providers to your logistics software. For less-than-truckload (LTL) and other freight movements, successful integration depends on more than a carrier name: you must verify accepted shipment identifiers, supported services, available milestones, account permissions, and update delivery methods. Start with the freight lanes and operational decisions you need to support, then test whether the API supplies usable data for those shipments.

This guide is for developers, logistics managers, and integration owners connecting freight visibility to a transportation management system (TMS), enterprise resource planning system (ERP), warehouse platform, or customer portal. The objective is not simply to retrieve a status. It is to give operations teams enough context to recognize delays, coordinate receiving, and resolve exceptions without treating missing data as a confirmed shipping problem.

What freight tracking data actually represents

Freight tracking is usually a record of reported shipment events, not a continuous location feed. A terminal arrival, customs release, delivery appointment, and proof of delivery describe different operational facts. They may originate from different organizations and arrive through separate systems.

LTL shipments share trailer capacity with other freight and may pass through multiple terminals. Other freight movements can involve an origin trucker, forwarder, ocean or air carrier, customs broker, and destination delivery provider. An API connection to one participant does not automatically expose every leg.

Data category	What to request	What not to assume
Shipment identity	Carrier, identifier type, identifier value, and account context where required	Every reference number works as a tracking lookup
Movement events	Pickup, terminal activity, departure, arrival, and delivery events where available	Every physical movement produces an event
Delivery planning	Estimated arrival, appointment information, and revisions	An estimated date is a confirmed receiving appointment
Exceptions	Original exception description, normalized category, and event time	A broad exception status explains the cause
Delivery evidence	Delivered event, delivery scope, and document availability	A delivered status includes a signed proof-of-delivery document

PRO numbers, bills of lading, and container numbers are not interchangeable

For LTL tracking, a carrier-assigned PRO number is a common shipment reference. A bill of lading (BOL) documents the shipment, but its number is not necessarily accepted by the same tracking endpoint. Purchase order numbers and shipper references may require account-specific lookup access or a separate search function.

Ocean freight introduces container numbers, booking references, and bills of lading. Air freight introduces air waybill references. A forwarder's house reference may identify a shipment within the forwarder's system without being usable directly with the underlying carrier. Store the identifier type and issuing party alongside the value; do not put every reference into an undifferentiated tracking-number field.

Define coverage at the shipment level

A carrier directory is a starting point, not proof that your freight is trackable. Treat coverage as a combination of carrier, service, geography, identifier, access rights, shipment lifecycle, and required fields. A provider can support a carrier while a particular service or document remains outside the integration's scope.

• Carrier and service: Confirm the actual LTL or freight service, rather than relying on a parent company name or parcel-service listing.
• Geography and leg: Verify the origin, destination, cross-border movement, and final delivery leg separately.
• Lookup method: Establish whether the API accepts the identifier your shipping workflow actually produces.
• Authorization: Determine whether public tracking is enough or carrier-account credentials and customer authorization are required.
• Field depth: Check whether the integration supplies basic statuses, terminal detail, estimates, appointment information, or documents.
• History and freshness: Ask about historical events, inactive shipments, refresh behavior, and any documented retention limits.

Keep two findings separate: an API's documented capabilities and the results observed on your test shipments. A successful lookup does not prove universal coverage. An unsuccessful lookup also does not establish that a service is unsupported; an incorrect identifier, missing permission, or shipment not yet entered into the source system may explain the result.

Where 17TRACK fits in the evaluation

For a team evaluating a multi-carrier tracking integration, the relevant 17TRACK product is its Tracking API. Use the official API documentation to evaluate the integration contract, and confirm your named freight carriers, service types, identifier formats, and required fields before committing to an implementation.

Do not infer complete LTL, ocean, air, or freight-forwarding visibility from a general tracking API description. Ask for confirmation using representative shipments. If an operational requirement includes appointment scheduling, dispatch, freight documents, or location telemetry, evaluate that requirement separately rather than assuming it is part of tracking.

Integration steps: from shipment references to operational alerts

1. Establish the shipment model and business outcome

Decide which actions the data must support. A receiving team needs delivery timing and appointment context; customer service needs a clear shipment history; an exception desk needs actionable delay information. These requirements determine what you must collect and when an alert is useful.

Create an internal shipment record independent of the API provider. Link it to orders, freight references, carriers, handling units, and transport legs where relevant. One order may move in several shipments, while one freight shipment may contain several orders. Avoid assuming a one-order-to-one-tracking-number relationship.

2. Validate access and identifier handling

Obtain the required credentials and confirm the provider's authentication method. Keep secrets in server-side configuration or a secret manager, not browser code. If access is account-specific, map each customer or business unit to the correct authorization context.

Preserve identifier values as strings so leading zeros are not lost. Apply only documented formatting rules. Use an internal lookup key that includes the carrier, identifier type, identifier value, and relevant account context. This reduces accidental collisions between references issued by different organizations.

3. Register or query shipments using the documented workflow

Some tracking integrations require shipment registration before updates become available; others support direct queries. Follow the chosen API's documented lifecycle rather than assuming a particular endpoint, payload, or response format. Capture per-shipment results when submitting batches so a partially successful request does not hide rejected records.

Separate invalid input, access denial, temporary source failure, and a valid lookup with no events. Each needs a different response. Repeating a malformed identifier indefinitely creates traffic without improving visibility.

4. Normalize events without discarding their meaning

Build a common event model for your logistics management workflow, but retain the original source status and description. Useful fields include internal shipment ID, transport leg, source carrier, source event identifier when provided, event time, received time, location, normalized status, and raw description.

Store event time separately from ingestion time. A recently received update may describe an older terminal event. Preserve timezone offsets when supplied, and identify timestamps whose timezone is unknown. Arrival at a destination terminal should not become final delivery simply because both events contain the word “arrival.”

5. Implement reliable update ingestion

Where webhooks are available, validate incoming requests using the provider's documented security mechanism. Durably store or queue accepted messages before acknowledging them, and process downstream work asynchronously. Design for duplicate delivery and out-of-order events unless the integration contract explicitly guarantees otherwise.

For polling, follow documented request limits and adjust the schedule to shipment state and operational urgency. Use controlled retries with backoff for transient failures. Respect server retry instructions when supplied. HTTP retry safety depends on request semantics, so do not assume every failed write can be repeated without creating duplicate work.

6. Connect statuses to actions, not just dashboards

Define who owns each exception. A missed pickup may belong to transportation operations, an appointment discrepancy to the receiving team, and a missing tracking reference to the shipping system owner. Include the source event and shipment context in the alert so the recipient can act without reconstructing the shipment history.

Maintain separate internal and customer-facing messages. Operations may need an unresolved source code; a customer needs a plain-language description that does not claim more certainty than the data supports. Never convert an absent estimate into a promised delivery date.

Coverage limits that change operational decisions

No event does not necessarily mean no movement. Freight can move between reported milestones. Distinguish “no recent update” from “carrier-reported delay.” A stale-data alert should prompt investigation, not automatically tell the customer that freight is lost or delayed.

Tracking milestones are not continuous GPS. If your workflow requires vehicle position, geofencing, or frequent location updates, request explicit confirmation of the location source, refresh behavior, and shipment-to-vehicle association. A timestamped terminal event is not live vehicle telemetry.

Transport completion may apply to only one leg. Delivery to a warehouse, terminal, or consolidation point may finish one provider's responsibility while the customer-facing journey continues. Model handoffs explicitly so an intermediate delivered event does not prematurely close the entire shipment.

Documents and piece-level outcomes require separate checks. A delivered event may not include a signed document, shortage notation, damage record, or handling-unit breakdown. For partial delivery workflows, confirm what the source reports and retain unresolved quantities until operations reconcile them.

Access and data standards are different problems. Standards such as the DCSA Track & Trace standards provide a reference for container-shipping event terminology and interfaces. They do not, by themselves, establish that a particular API offers access to your shipment or supports your required carrier connection.

Test coverage and monitor data quality before scaling

Build a proof of concept around your actual freight mix. Include normal deliveries, active in-transit shipments, cross-border movements where relevant, handoffs, missing references, and exception cases. Select examples across the carriers and services that matter to your operation rather than using only the easiest successful lookups.

• Lookup correctness: Does the response identify the intended shipment rather than a similar or reused reference?
• Milestone completeness: Which operationally useful events appear, and which require another source?
• Timestamp quality: Are event time, received time, and timezone interpretation consistent?
• Estimate handling: Can the system distinguish an estimate, a revision, and an appointment?
• Failure behavior: Do invalid input, authorization failures, and temporary outages produce distinguishable outcomes?
• Recovery: Can the integration reconcile missed messages or recover after an interruption?

For API monitoring, separate technical health from shipment visibility. Track request failures, processing lag, webhook rejection, and queue backlog alongside shipments with no first event, stale histories, or unresolved identifiers. A successful HTTP response can still contain no useful shipment information.

Define each metric's denominator. “Successful lookup” might mean an accepted request, a recognized shipment, or a shipment with usable milestones; those are different measures. Set acceptance criteria before the pilot and document results by carrier, service, and lane. Expand only when the connection supports the intended operational decisions, with a named fallback for uncovered cases.

FAQ

Can I track LTL freight using only a BOL number?

Sometimes, but acceptance depends on the carrier and integration. A service may require a PRO number, account credentials, or another reference. Confirm the lookup method before building a workflow around BOL-only tracking.

Does a freight tracking API replace a TMS?

Not by itself. Tracking supplies visibility data. Transportation planning, tendering, rating, appointment management, and settlement are separate functions that may remain in your TMS or other operational systems.

Why does the carrier website show an update before my system?

Possible causes include source synchronization, API refresh timing, webhook delivery, or your own processing backlog. Compare the source event time with receipt and processing times to locate the gap. Do not assume the carrier website and API use identical update paths.

Can one API follow an international freight shipment end to end?

It may, if the required participants and shipment references are connected. Verify origin pickup, main carriage, customs-related milestones, and destination delivery separately. A connection covering the main transport leg does not automatically include the others.

What should happen when tracking data becomes stale?

Apply a threshold appropriate to the service and shipment stage, then create a data-quality or operational review task. Show the last known event and its time. Escalate to the carrier or forwarder when necessary, without presenting missing updates as a confirmed delay.

Sources

• 17TRACK Tracking API — official entry point for evaluating the tracking API offering.
• 17TRACK API documentation — reference for checking the implementation contract and integration requirements.
• DCSA Track & Trace standards — container-shipping tracking standards and event-model context.
• RFC 9110: HTTP Semantics — HTTP method semantics, idempotency, and retry-related protocol considerations.