Skip to content

Get started

Getting started

Make your first Navo24 call in two minutes, then get a key for the full surface.

Navo24 is freight intelligence you call directly: container and air-waybill tracking, sailing schedules and reliability, spot rates and load planning. Each product ships a REST API, and most ship an MCP server too, behind one bearer key.

Make a call with no account

The fastest way to see real data is the public container lookup. It needs no key.

curl -X POST https://api.trackingmcp.com/v1/track/public \
  -H "Content-Type: application/json" \
  -d '{"reference":"MEDU1234562"}'

You get back a normalised status, the vessel, the milestones and an ETA that says whether it is still a forecast:

{
  "ok": true,
  "data": {
    "identifier": "MEDU1234562",
    "identifier_type": "container_id",
    "carrier_code": "MSCU",
    "carrier_name": "MSC",
    "status": "in_transit",
    "eta": "2026-07-03T06:00:00Z",
    "eta_is_estimated": true,
    "origin": "Ningbo",
    "destination": "Rotterdam",
    "vessel": { "name": "MSC TERESA", "lat": null, "lng": null },
    "events": [
      {
        "description": "Loaded on vessel",
        "location": "Ningbo",
        "event_code": "LOAD",
        "unlocode": "CNNGB",
        "datetime": "2026-06-18T22:10:00Z",
        "actual": true
      }
    ]
  }
}

Four fields carry most of the meaning:

  • identifier_type is what we decided the reference actually is, which can differ from your guess.
  • eta_is_estimated is true while the ETA is a forecast, false once it is the real arrival, and null when we hold no ETA at all. A date on its own is not a promise.
  • actual on an event is true for something that happened and false for something planned. Never read a planned move as a fact.
  • carrier_code, origin, destination and unlocode are null when the carrier named nothing we could resolve, rather than guessed.

Public endpoints are rate-limited per IP and meant for a quick check. Anything portfolio-shaped needs a key.

Get an API key

  1. Sign up at trackingmcp.com.
  2. Open the developer settings and mint a key. It carries a product prefix, for example tmcp_ for tracking.
  3. Send it as a bearer token on every authed request.
curl https://api.trackingmcp.com/v1/containers/summary \
  -H "Authorization: Bearer tmcp_YOUR_API_KEY"
{
  "ok": true,
  "data": {
    "total_active": 128,
    "exceptions": 6,
    "arriving_this_week": 14,
    "demurrage_risk_usd": 4820.5,
    "containers": []
  }
}

Start tracking a shipment

The keyed surface takes two required fields, identifier and identifier_type. The type is one of container_id, bill_of_lading or booking.

curl -X POST https://api.trackingmcp.com/v1/containers \
  -H "Authorization: Bearer tmcp_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"identifier":"MEDU1234562","identifier_type":"container_id"}'
{
  "ok": true,
  "data": {
    "id": "8f1c2d4e-6a3b-4f52-9c70-11ab22cd33ef",
    "identifier": "MEDU1234562",
    "status": "in_transit",
    "carrier_code": "MSCU",
    "source": "direct_carrier"
  }
}

Keep the id. It is a UUID, and every other container endpoint is keyed on it rather than on the container number. A box we accept but cannot resolve on the first pass comes back with "status": "unknown" and a warning, and fills in within minutes as the re-poll runs.

The same key works across the family where a product accepts the family credential. Read the authentication guide for the full picture on prefixes and headers.

Where to go next