Does it fetch live tracking from carriers?

No. It normalizes JSON you send (tracking numbers plus optional pre-fetched carrier payloads). It does not call UPS, FedEx, USPS, or DHL APIs.

Do I need carrier API keys?

No for this API. You obtain tracking responses through your own integrations and pass them in the request body.

What if I only send tracking numbers?

The API can infer carrier from common patterns and return a minimal shipment with warnings. Full timelines need a payload from your carrier integration.

What is the canonical status taxonomy?

Statuses map to a fixed set such as pending, label_created, accepted, in_transit, out_for_delivery, delivered, exception, failed_attempt, returned, cancelled, customs_cleared, and unknown. Original carrier wording is preserved on events.

No. The service is fully stateless.

Where are pricing and quotas defined?

On RapidAPI: Basic is free with 100 requests per month; Pro is $9.99/month with 10,000 requests; Ultra is $49.99/month (recommended) with 100,000 requests; Mega is $99.99/month with 250,000 requests. Overage pricing is shown on the live listing.

Can I request a new carrier adapter?

Yes. Open a thread on RapidAPI discussions for the Shipping & Tracking Data Normalization API with the carrier name and a redacted sample JSON payload.

Normalize Carrier Tracking Data Into One Shipment Schema

One API call turns UPS, FedEx, USPS, DHL, and other tracking payloads into a consistent canonical format — unified status taxonomy, chronological events, delivery metadata, provenance, and confidence for dashboards, support, and analytics.

Try Shipping & Tracking Normalization API Basic on RapidAPI: 100 requests/month free

Stop maintaining four different carrier parsers. Replace ad-hoc status strings and nested payloads with one deterministic schema. Ship unified tracking UIs and notifications faster—your team spends time on product, not re-mapping every carrier API revision.

Real-world use cases

Normalize carrier webhook or poll responses before workers, queues, or notification services consume them.
Power marketplace and storefront order-tracking pages with one JSON shape for every carrier.
Unify support dashboards so agents see the same timeline language across UPS, FedEx, USPS, and DHL.
Feed warehouses and BI with canonical events for on-time delivery and exception rates.
Trigger alerts on canonical status changes (e.g. out_for_delivery → delivered) without carrier-specific rules.
Batch many tracking numbers in a single POST for nightly reconciliation jobs.

Why not build your own normalizer?

Carrier field names and nesting change without notice
Status text varies wildly for the same milestone
Timestamps and time zones are inconsistent
Each new carrier multiplies edge cases

Cross-carrier normalization is ongoing work. This API centralizes mappings so you benefit when payloads drift.

Who this API helps

E-commerce, marketplaces, and fulfillment / OMS teams
Logistics products building multi-carrier tracking views
Customer support and CX platforms
Analytics teams merging tracking from many sources
Developers who need repeatable, testable normalization (not scraping or LLM guessing)

Before and after normalization

Carriers use different status wording and structures. The API maps them into one predictable shape (illustrative).

Before (carrier-style snippet)

{
  "activity": [
    { "desc": "On vehicle for delivery", "city": "Austin" }
  ]
}

After (canonical shape)

{
  "currentStatus": "out_for_delivery",
  "events": [
    {
      "canonicalStatus": "out_for_delivery",
      "originalCarrierStatus": "…",
      "timestampIso": "…"
    }
  ],
  "provenance": { … },
  "confidence": { … }
}

What the API does

Send POST /normalize with an inputs array. Each item has a trackingNumber, optional carrier hint, and optional payload (pre-fetched carrier JSON). The response includes results, shipments, errors, and metadata. Per-item failures do not fail the whole request.

Unlike live trackers or AI extractors, this API operates on structured JSON you already have and returns a consistent canonical schema every time—deterministic mapping, not probabilistic parsing.

Deterministic by design

The same input always produces the same normalized output. No hidden randomness—ideal for tests, CI, and production pipelines that need repeatable results.

Carriers: first-class normalizers vs custom

The carrier string selects a normalizer when you supply a payload. UPS, FedEx, USPS, and DHL have dedicated parsers tuned to common response shapes. Other labels (including custom) use shared heuristics; unknown carriers still normalize with best-effort extraction and often lower confidence.

First-class carrier keys

Use these in carrier when you know the source:

UPS — ups
FedEx — fedex
USPS — usps
DHL — dhl, dhl_ec

Also recognized (custom / regional)

Additional carrier identifiers in the engine include regional and logistics labels—for example canada_post, royal_mail, australia_post, hermes, dpd, gls, ontrac, lasership, amazon_logistics, plus custom and unknown. With a payload, the API picks the best matching normalizer; without payload, carrier may be inferred from the tracking number pattern.

Declared carrier that does not match detected pattern can produce warnings and reduced confidence—check confidence.warnings on each shipment.

Want a first-class adapter for another carrier? Request it on RapidAPI discussions — include a redacted sample payload and the carrier name.

Request & response schema

Endpoint: POST https://shipping-tracking-data-normalization.p.rapidapi.com/normalize with Content-Type: application/json, plus x-rapidapi-key and x-rapidapi-host.

The body must include an inputs array (each object: trackingNumber required; carrier and payload optional).

View request body fields · View success response · View HTTP error body · View per-item / in-body codes

Field	Required	Type	Description
`inputs`	Yes	array	Non-empty array of tracking inputs. Order is reflected in `results`.
`inputs[].trackingNumber`	Per item	string	Tracking identifier. Empty values yield per-item errors.
`inputs[].carrier`	No	string \| null	Hint: `ups`, `fedex`, `usps`, `dhl`, `custom`, etc. Omitted → pattern inference when possible.
`inputs[].payload`	No	any	Optional raw JSON from your carrier integration (API response, webhook body). Required for full event timelines.

On success the handler returns HTTP 200 with JSON containing results, shipments, errors, and metadata (partial success allowed).

Field	Type	Description
`results[]`	array	Per input: `index`, `trackingNumber`, `shipment` (canonical object or null), optional `error`, optional `warnings`.
`shipments[]`	array	All successfully normalized shipments (canonical schema).
`errors[]`	array	Item-scoped errors: `code`, `message`, optional `trackingNumber`, `index`, `detail`.
`metadata`	object	Aggregates such as `totalInputItems`, `normalizedCount`, `errorCount`.

Canonical shipment (summary): identifiers (trackingNumber, …), carrier, currentStatus, originalCarrierStatus, events[] (canonicalStatus, originalCarrierStatus, timestampIso, location, eventType, …), optional delivery (estimates, POD, signedBy—never fabricated), provenance, confidence (0–1 score and warnings).

When the request is invalid, the API returns a non-200 status and {"error":"...","message":"..."} (not the success envelope):

HTTP	`error`	Meaning
400	`INVALID_REQUEST`	Missing or invalid `inputs` array
400	`INVALID_JSON`	Body is not valid JSON
413	`PAYLOAD_TOO_LARGE`	Body exceeds 25MB
500	`INTERNAL_ERROR`	Unexpected server failure

Example: {"error":"INVALID_REQUEST","message":"Request body must include \"inputs\" array"}

Code	HTTP	Description
`INVALID_REQUEST`	`400`	Top-level body invalid (e.g. missing `inputs` array).
`INVALID_REQUEST`	`200`	Per-item: `null` or non-object entry in `inputs`.
`INVALID_JSON`	`400`	Request body is not valid JSON.
`INVALID_TRACKING_NUMBER`	`200`	Per-item: empty or missing tracking number.
`INVALID_PAYLOAD`	`200`	Per-item: payload is not an object when required by normalizer.
`NO_TRACKING_DATA`	`200`	Per-item: could not derive events/status from payload.
`PARSE_ERROR`	`200`	Per-item: unexpected failure while normalizing that item.
`PAYLOAD_TOO_LARGE`	`413`	Request size exceeds 25MB.
`INTERNAL_ERROR`	`500`	Unhandled server exception.

Per-item problems still return HTTP 200 with populated errors / results[].error; other items in the batch still normalize.

Try it in the playground

Pick a sample request (or edit JSON), add your RapidAPI key, run, then copy code in the language you use below. The key is sent only to RapidAPI.

RapidAPI Key (required)

Sample request

Loads a template into the JSON editor; you can change anything before running.

Request body (JSON)

Subscribe on RapidAPI for production keys and plan details.

Get code

Generates a snippet for the JSON currently in the playground. Choose language, refresh if you edited the body, then copy.

Integration time: Under 5 minutes with any stack that can send HTTP POST and JSON headers.

Real-world examples

1. Marketplace batch (multiple carriers, numbers only)

Your worker already resolved tracking numbers from orders. Send them in one inputs array; add payload later when your carrier integration returns JSON for full timelines.

{
  "inputs": [
    { "trackingNumber": "1Z999AA10123456784", "carrier": "ups" },
    { "trackingNumber": "9405511899223191234567", "carrier": "usps" }
  ]
}

2. UPS activity payload (pre-fetched API response)

You stored the carrier JSON from your integration. Pass it as payload with the same trackingNumber and carrier: "ups" for a rich normalized timeline.

{
  "inputs": [
    {
      "trackingNumber": "1Z999AA10123456784",
      "carrier": "ups",
      "payload": {
        "shipment": {
          "package": {
            "activity": [
              { "date": "2024-01-14", "time": "08:00", "description": "Picked up", "location": { "address": { "city": "Chicago" } } },
              { "date": "2024-01-15", "time": "10:00", "description": "In transit", "location": { "address": { "city": "Louisville" } } }
            ]
          }
        }
      }
    }
  ]
}

Pricing & tiers (RapidAPI)

Built for production logistics and commerce stacks that need deterministic, canonical tracking output across heterogeneous carriers—customer portals, support tools, and data pipelines.

Current plans on RapidAPI:

Basic

$0/mo

Primary: 100/month

Pro

$9.99/mo

Primary: 10,000/month

Recommended

Ultra

$49.99/mo

Primary: 100,000/month, then $0.003 each

Mega

$99.99/mo

Primary: 250,000/month, then $0.002 each

If RapidAPI pricing or quotas change, the live listing is authoritative.

What to expect

Successful calls return HTTP 200 and Content-Type: application/json with results, shipments, errors, and metadata. Invalid top-level requests return 400, 413, or 500 with {"error":"...","message":"..."}. Use your RapidAPI key on every request. Stateless — no payload storage.

About this API

Who Should Use This API

Logistics and shipping apps, e-commerce platforms, and teams unifying carrier tracking data.

Also Known As

Shipping tracking normalizer, carrier tracking API, tracking data standardization.

Shipping & Tracking Normalization API

Normalize tracking data from UPS, FedEx, USPS, DHL, and other carriers into one canonical shipment schema. One API call for single or mixed tracking numbers—with or without pre-fetched carrier payloads. Get unified status, chronological event timeline, location, delivery metadata, provenance, and confidence. Built for marketplaces, fulfillment systems, support dashboards, and analytics that need a single data model across carriers.

What This API Does

**Normalizes** carrier-specific tracking payloads (or tracking numbers only) into one consistent JSON shape: identifiers, carrier, currentStatus, events (timeline), delivery, provenance, confidence
**Single schema** — Every shipment has the same structure regardless of carrier; status is mapped to a fixed taxonomy (pending, in_transit, delivered, exception, etc.)
**Mixed carriers in one request** — Send an array of inputs (trackingNumber, optional carrier, optional payload); get results, shipments, and item-scoped errors. One bad item does not fail the rest
**Carrier detection** — When carrier is not declared, the API infers it from tracking number patterns; mismatch between declared and detected yields a warning and lower confidence
**Provenance & confidence** — Every shipment includes data source type, parsing strategy, and a 0–1 confidence score so you can filter or flag low-confidence items
**No carrier API keys** — You send tracking numbers and (optionally) payloads you already have; the API does not fetch from carriers. Stateless, 25MB max

**One pipeline, one schema.** Build unified tracking views, notifications, or analytics without per-carrier parsing or status mapping.

Key Features

**Stateless** — No data stored or logged; 25MB max request
**UPS, FedEx, USPS, DHL** — First-class normalizers; custom/unknown for other carriers or user-provided payloads
**Canonical status taxonomy** — pending, label_created, accepted, in_transit, out_for_delivery, delivered, exception, failed_attempt, returned, cancelled, customs_cleared, unknown
**Event timeline** — Chronological events with canonicalStatus, originalCarrierStatus, timestampIso, location, eventType
**Delivery metadata** — estimatedDeliveryDate, actualDeliveryTimestamp, signedBy, proofOfDelivery when present (never fabricated)
**Partial success** — Per-item results and errors; metadata with normalizedCount and errorCount

Use Cases

**Marketplace order tracking** — Normalize tracking from multiple sellers and carriers into one view for customer dashboards
**Customer support** — Show agents a unified timeline and status instead of carrier-specific jargon
**Analytics & BI** — Ingest normalized events to analyze delivery performance across carriers
**Notifications** — Trigger alerts when canonical status changes (e.g. out_for_delivery → delivered)
**Fulfillment & OMS** — One schema for all inbound tracking data

Frequently asked questions

No. It normalizes JSON you send—tracking numbers plus optional pre-fetched carrier payloads. It does not call UPS, FedEx, USPS, or DHL APIs on your behalf.
No. You use your RapidAPI key for this endpoint only. You obtain carrier data through your own contracts and integrations, then POST it here to normalize.
The API infers carrier when possible and returns a minimal shipment (often pending) with warnings that full normalization needs a payload. Use that for display or to decide which carrier API to call next.
Statuses map to a fixed set such as pending, label_created, accepted, in_transit, out_for_delivery, delivered, exception, failed_attempt, returned, cancelled, customs_cleared, and unknown. Original carrier wording is preserved on each event as originalCarrierStatus.
25MB per request.
No. The service is fully stateless.
On RapidAPI: Basic is free with 100 requests/month; Pro ($9.99/mo) includes 10,000/month; Ultra ($49.99/mo, recommended) includes 100,000/month; Mega ($99.99/mo) includes 250,000/month—with overage rules as shown on the listing.
Yes. Open a thread on RapidAPI discussions with the carrier name and a redacted sample JSON payload.

Browse all APIs in the catalog →