DHL Tracking API for Developers

Use C2W Package Tracking API to retrieve DHL shipment information through RapidAPI. The documented endpoint accepts a tracking number and returns JSON for your application. Webhooks are not supported.

How to request DHL tracking

Subscribe on RapidAPI and keep your credentials on your server.
Send your shipment’s tracking number as trackingNumber to GET /TrackingPackage.
Check the HTTP response before reading tracking fields. Use the API reference for headers and schema.

curl --get 'https://trackingpackage.p.rapidapi.com/TrackingPackage' \
  --data-urlencode 'trackingNumber=YOUR_TRACKING_NUMBER' \
  --header 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  --header 'X-RapidAPI-Host: trackingpackage.p.rapidapi.com'

Add an Authorization header only if it was issued for your integration. This example uses a placeholder; it does not query a real shipment.

Illustrative response, not a live shipment

This synthetic subset illustrates documented field names. It is not a recorded DHL response or a guarantee that every shipment supplies these values.

{
  "TrackingNumber": "YOUR_TRACKING_NUMBER",
  "Carrier": "DHL",
  "Delivered": false,
  "Status": "In transit"
}

See authentication and error handling. Keep credentials server-side and treat network failures separately from shipment status.

Plan polling and cost before subscribing

Webhooks are not supported. Your application schedules requests and customer notifications. Results may be cached; a successful call does not imply a new carrier scan.

Example: 25 active shipments checked four times per day use 100 requests, before retries and manual refreshes. The Pro plan includes 150 requests/day at $9.99/month, leaving 50 requests of headroom. This is a workload example, not a recommended polling interval.

The free plan includes 5 requests/day for evaluation. Space requests within the rate limit and stop routine polling when your workflow is complete. Compare plans and request budgets; confirm applicable terms in RapidAPI.

Evaluate Express and eCommerce as distinct services.

C2W lists DHL Express and DHL eCommerce support. Test the particular DHL service and route you need; a DHL carrier label does not establish coverage for every DHL business unit.

Preserve service and handoff context

If your shipping workflow includes a delivery partner, keep the original shipment identifier and available carrier-event text. Do not infer that a different partner identifier can automatically be queried through the same integration.

Handle event times without assumptions

The C2W reference contains sample timestamps without an explicit timezone offset. Preserve those values for display until your integration establishes the timezone. Do not reinterpret them as UTC simply because they look like ISO dates.

Separate DHL’s API features from C2W’s

DHL publishes its own Shipment Tracking Unified API. Its supported business units and access conditions are not a feature list for C2W. C2W uses an on-demand request workflow and does not support webhooks.

Fields to consider in your application

Integration considerations, not guaranteed field availability
Field	Application handling
`Carrier / ServiceType`	Retain available service context for Express or eCommerce workflows.
`TrackingDetails`	Keep carrier wording when showing handoffs and progress.
`EventDateTime`	Do not add a timezone that the returned value does not specify.

Available values depend on the shipment and carrier data. Empty strings, null values, and absent fields should not break your interface. These are schema notes, not a recorded DHL production response.

Before going live

Test delivered, in-transit, unavailable-data, and exception cases for your services. Establish your polling schedule, request headroom, and support process. Use our integration guide and request-budget examples.