Call C2W from your server, check the HTTP response, validate the returned object, and update your application only when usable tracking data is available. Keep transport failures separate from the shipment’s own status.
Download the server-side examples
The examples use the documented single-number endpoint. They take secrets from environment variables, omit optional Authorization when it is absent, set a timeout, reject unexpected response shapes, and avoid logging raw shipment data.
Set RAPIDAPI_KEY and TRACKING_NUMBER in your server environment. Set TRACKING_API_AUTHORIZATION only if C2W issued an additional credential for your integration.
node tracking-client.mjs
python tracking_client.pyThese examples have local automated checks using synthetic responses. They have not been certified against live carrier shipments and do not automatically retry billable calls. The API reference explains the response fields.
Keep three kinds of state separate
| Situation | What it means | Application response |
|---|---|---|
| HTTP or network failure | Your request did not produce a usable successful response. | Keep the last known shipment state and show an update failure. |
| Unexpected or incomplete JSON | A response exists, but required application fields are missing or invalid. | Use an unavailable-data state; do not guess delivery. |
| Valid shipment status | The response contains usable tracking information. | Update your display using the returned data and your business rules. |
For example, a 429 response is a request-limit issue, not a shipment delay. An empty event array does not mean the parcel has been lost. A false delivered flag does not establish that a parcel is late.
Design the polling loop around your quota
- Track the number of active shipments across all creation dates.
- Choose an update interval based on your workflow; more calls do not guarantee more carrier scans.
- Spread jobs over time so the queue respects both daily and per-second limits.
- Reserve request headroom for manual refreshes and retries.
- Stop routine polling when your application considers the shipment complete, with any final reconciliation handled explicitly.
Use daily request-budget examples before scheduling jobs. C2W does not support webhooks, so any email or push-notification workflow belongs in your application.
Make retries a deliberate policy
Inspect failures before retrying. Authentication and malformed-input failures usually require a configuration or request change. For temporary failures, use a bounded retry count with increasing delays and jitter. Honor a valid Retry-After value when present.
Each retry can consume quota. Avoid retrying an entire batch of your own jobs because one shipment failed, and avoid parallel retries that exceed your rate limit. The downloadable examples intentionally make one attempt so retry costs stay visible to the caller.
Preserve the details that affect correctness
- Tracking numbers: keep them as strings to preserve leading zeroes.
- Timestamps: do not add a UTC interpretation when no offset is provided.
- Missing fields: handle null, empty strings, and absent optional fields.
- Status values: allow an unknown state rather than assuming one sample contains every possible value.
- Notifications: compare the current result with the last stored event before notifying the customer.
- Logs: use your own correlation ID and error category; omit API keys, shipment identifiers, and recipient data.
Evaluate with your own shipments
Before migration, test representative delivered, in-transit, exception, and unavailable-data cases for each carrier service. Compare the fields your application actually needs. Record your test date, service, result category, and observed latency without publishing shipment identifiers.
No production latency, uptime, or customer-outcome claim is implied by these local examples. For data-freshness requirements, batch workflows, or support commitments, discuss the integration with C2W.