OpenAPI specification
The Tracking One API is described by machine-readable OpenAPI 3.0 documents — one per product, sharing nothing — and every reference page on this site is generated from them. They are published exactly as the API produces them, so anything a page here says about a path, a parameter or a response shape, the file says too — there is no hand-written copy to drift out of date.
Hand one to a tool and you get the endpoints, the query parameters, the response schemas and the examples without typing any of it.
Download
| Document | What it describes | |
|---|---|---|
| Container Tracking API | Ocean freight: containers, bills of lading, booking numbers, and the list of carriers we track. | Download JSON |
| Air Tracking API | Air cargo by air waybill, and the list of airlines we track. | Download JSON |
| Widget integration | The contract for the proxy endpoint the tracking widgets call on your server. | Download JSON |
Each also has a stable URL you can fetch in a script or point a tool at directly:
curl -O https://developer.tracking.one/container-tracking-api-v1.json
curl -O https://developer.tracking.one/air-tracking-api-v1.json
curl -O https://developer.tracking.one/widget-integration-v1.json
They are plain static files — no key, no headers, no rate limit.
What to do with them
Explore in Postman or Insomnia
Both import an OpenAPI document as a collection: Import → File (or paste one of the URLs above). You get every request pre-built with its parameters and examples.
Set your API key once as a collection-level bearer token rather than per request — Authentication covers the header itself. The two carrier endpoints need no key at all, so they are the ones to try first.
Generate a client
Point a generator at the file and skip writing the transport layer:
npx @openapitools/openapi-generator-cli generate \
-i https://developer.tracking.one/container-tracking-api-v1.json \
-g typescript-fetch \
-o ./tracking-one
Swap -g for the language you want — python, go, java, php and the rest are all in openapi-generator-cli list.
Generate the client you actually need, though: the container document carries 22 schemas, and a generated client for all of them is a lot of code for two endpoints. A hand-written call plus generated types is often the better trade.
Validate, mock or diff
The documents work anywhere OpenAPI does — Stoplight, Redocly, Swagger UI, Prism for a local mock, openapi-diff to see what changed between two versions you have kept.
One thing worth knowing before you import
The widget document describes an endpoint you host, not one we serve. It deliberately has no servers block: /api/tracking/ocean and /api/tracking/air are paths on your server, the ones the widgets call and that forward to us with your API key attached. Use it to check your proxy against the contract — do not point a client generated from it at the API host. The widget guide has the whole picture, with working proxy samples.
Versions and changes
The version is in the path and in the filename: everything above is v1, published as …-v1.json. Within v1 the changes are additive — new endpoints and new fields appear, existing fields are not renamed or removed — so a client that ignores unknown fields keeps working across updates. A change that would break one goes into a new version with its own prefix and its own file.
There is no changelog feed. If you pin a copy of a document, diff it against the current one to see what moved.
Ready to send a request instead? Getting started has the base URL and the first call.