Get started

Authentication

Bearer keys, the per-product prefixes, and the one family credential.

Every authed request carries an API key as a bearer token in the Authorization header.

curl https://api.trackingmcp.com/v1/containers \
  -H "Authorization: Bearer tmcp_YOUR_API_KEY"

A few products also accept the key in an x-api-key header. Bearer is the norm across the family, so prefer it.

Key prefixes

The prefix names the product a key was minted for. Read it as the product tag, not a secret you can shorten.

Product	Prefix	Base URL
TrackingMCP	`tmcp_`	`https://api.trackingmcp.com`
AirCargoMCP	`tmcp_` (family)	`https://api.aircargomcp.com`
SchedulesMCP	`smcp_`	`https://schedulesmcp-api.fly.dev`
LoadingMCP	`lmcp_`	`https://loadingmcp-api.fly.dev`
FreightRatesMCP	`frm_`	`https://freightratesmcp.com`

Public endpoints

Some routes are open and need no key at all: the public container lookup, air-waybill prefix resolution, and most of the SchedulesMCP /public/* surface. They are rate-limited by IP. The one exception is the lane endpoint GET /public/schedules, which needs a key; it kept its /public path when that changed, so the prefix no longer tells you whether a key is required. The reference marks each endpoint as No key or API key, and that badge is the answer.

The family key

AirCargoMCP validates the shared Navo24 family credential, so a tmcp_ key that works for tracking also tracks air waybills. Other products keep their own prefix. If you hold a single account across the suite, you will usually carry one key per product plus the family key for air cargo.

Keeping keys safe

Send keys only from your backend. Never ship a live key in browser code or a mobile bundle.
Rotate on exposure. Mint a new key, cut the old one over, then revoke it.
Scope by environment. Keep a separate key for staging so you can revoke it without touching production.

If a request is missing or has a bad key, the API answers 401 with an error envelope. See errors and rate limits.