There is no universally best courier tracking API, and any article that ranks them on a feature grid is guessing. The variable that matters most, how well a provider normalises inconsistent carrier data into a usable event stream, is not published by anyone and cannot be inferred from a carrier count. This is a framework for testing it yourself, using external benchmarks that do exist.
Why can't you just compare tracking APIs on a feature list?
Because the hardest part of the job is invisible in a feature list. Every vendor offers tracking status, estimated delivery dates and webhooks. None of that tells you what happens when a regional carrier returns a status that maps to nothing, repeats an event, or reports delivery before the last scan.
The underlying reason is that there is no cross-carrier standard for tracking event codes. Universal Postal Union (UPU) standards govern the postal network only: S10 defines the 13-character international item identifier, M40 (EMSEVT V3) covers item-level tracking events, and M33 and M52 (ITMATT) cover item attribute and customs data. Outside the postal network, UPS, FedEx, DHL and Amazon each use proprietary code sets, and as of 2026 no cross-carrier standard is emerging.
That absence is the whole problem. Every tracking API is a large, continuously maintained set of judgements about how hundreds or thousands of incompatible vocabularies map into one. Those judgements differ between vendors, are not documented in comparable form, and largely determine whether your delivery notifications are correct.
Worth knowing: two vendors integrating the same carrier do not necessarily return the same events for the same parcel.
What do published carrier counts actually tell you?
Very little on their own, because each vendor counts differently. The figures below were observed on vendor websites in August 2026. They are self-reported, not independently verified, and not directly comparable.
| Vendor | Self-reported claim | Unit as stated |
|---|---|---|
| Ship24 | 2,500+ | courier and 3PL integrations |
| AfterShip | 1,300+ (a June 2026 post on its own blog put the total at 1,326) | carriers |
| Easyship | 550+ | courier services |
| EasyPost | 100+ | carriers |
Read the units, not the numbers. One vendor counts integrations, which can include third-party logistics providers alongside couriers. Another counts carriers. Another counts courier services, where a carrier offering express, economy and returns products can plausibly be counted once or three times, and regional franchises of a global brand may be rolled up or listed separately.
Depth is invisible in these figures too. A direct API integration and a low-frequency file-based feed both count as one, and counts rarely distinguish actively maintained integrations from those that exist but rarely return data.
Carrier count is therefore a screening signal, not a decision criterion. What matters is whether the provider covers your carriers, at the depth you need, and only your own tracking numbers can establish that.
What criteria actually separate one tracking API from another?
Six, in roughly this order of impact.
Coverage of your carrier mix
Coverage is only meaningful when scoped to the carriers you actually use, including the ones you will use next year. The Pitney Bowes Parcel Shipping Index 2026, in its US-only edition, reports that alternative carriers including OnTrac, GLS, Veho, UniUni and SpeedX grew 127 per cent to 1.8 billion parcels, doubling their revenue share from 3.4 per cent to 7.2 per cent, driven substantially by Shein and Temu volume.
Pitney Bowes explicitly names delivery tracking and reliability as this segment's weak point, which is a direct instruction to anyone evaluating a tracking API: test the alternative carriers, not the incumbents.
Normalisation quality
Normalisation is the mapping from carrier-specific status vocabularies to a single set of statuses your code can rely on. Absent any cross-carrier standard, this is where providers genuinely differ, and where problems surface as wrong customer notifications rather than as errors in your logs.
Latency and data freshness
These are two different things and both matter. Latency is how quickly the API responds. Freshness is how old the carrier data behind that response is, which depends on how often the provider polls or receives pushes from each carrier.
Google's Package Tracking Early Adopters Program is a rare objective yardstick. Its documentation, last updated 14 July 2026, requires participating carrier APIs to respond in 700ms average or less, with a 95th percentile of 1,000ms or less. The programme is closed to new partners, but the numbers remain a published external bar for a vendor's response times.
Webhook reliability
Polling does not scale and does not deliver events promptly. What you need to know about webhooks is behavioural: retry policy and backoff, payload signing, and whether you can replay missed events after an outage on your side.
Event granularity
Some providers return only a current status. Others return the full event history with timestamps, locations and carrier-original codes alongside the normalised ones. Access to the raw code matters, because it lets you handle edge cases the provider has not mapped yet rather than waiting for them to.
Carrier detection
Carrier detection identifies the correct carrier from a tracking number alone. It is the most common single point of failure in a real deployment, particularly for cross-border parcels, ambiguous number formats and shipments that change hands mid-journey. It is easy to test and rarely tested.
What is the emerging requirement any tracking API will need to meet?
Agentic commerce protocols are starting to define what a fulfilment event must contain, which turns tracking data into a compliance requirement rather than a nice-to-have.
Google's Universal Commerce Protocol (UCP), announced 11 January 2026, requires a fulfillment event to carry "tracking number" and "tracking url" for any event type other than "processing", plus an optional "carrier" field. Participating means producing both at dispatch, for every carrier, without exception.
The contrast is instructive. The Agentic Commerce Protocol (ACP) from OpenAI and Stripe has an order status enum that includes "shipped", but its published webhook reference contains no tracking number, tracking URL or carrier field anywhere. Two protocols take opposite positions on whether tracking data belongs in the commerce layer at all.
Worth knowing: the practical question for a vendor is not "do you support UCP". It is whether the API returns a working tracking URL for every carrier it claims to cover, because per-carrier URL maintenance is exactly the long-tail work that separates deep integrations from shallow ones.
How do you run a fair trial with your own tracking numbers?
Build the test around parcels whose outcome you already know. The point is not whether the API responds, it is whether it is right.
- Assemble a representative sample. Pull a few hundred recent tracking numbers from your own shipments, weighted to your real carrier mix, including international, returns and smaller regional carriers.
- Include known-difficult cases deliberately. Add parcels that were delayed, redirected, returned to sender, or that changed carrier mid-journey. Average-case behaviour is similar across vendors. Edge-case behaviour is not.
- Test carrier detection blind. Submit numbers without specifying the carrier, and measure how often the provider gets it right and what it does when it cannot.
- Run the same sample through every shortlisted vendor on the same day. Results gathered a week apart introduce differences that have nothing to do with the vendors.
- Measure freshness, not just latency. For parcels in transit, compare the most recent event the API returns against the carrier's own tracking page at the same moment. Separately, record average and 95th percentile response times and compare them to Google's 700ms and 1,000ms figures.
- Test webhooks by breaking them. Take your endpoint offline, bring it back, and see what arrives. Behaviour under failure is the webhook property worth testing.
- Read the normalised events as a human. Take fifty parcels and read each event history end to end. Duplicates, out-of-order timestamps, contradictory statuses and delivered-before-final-scan errors are obvious to a person and invisible to an uptime dashboard.
Do not skip the last step. It is slow, it produces no number, and it will tell you more than everything above it combined.
What should you ask a vendor directly?
Ask questions whose answers are verifiable, and treat vague answers as answers.
- How do you count the carriers in your published figure: by carrier, by service, or by integration?
- For my carrier list, which are direct API integrations and which are obtained another way, and how often is each polled?
- Do you expose the original carrier status code alongside your normalised status?
- What is your webhook retry policy, and can I replay events after an outage on my side?
- How do you handle a parcel that changes carrier mid-journey or is issued a second tracking number?
- What happens when carrier detection fails: an error, a guess, or an explicit unknown?
- How quickly do you add an unsupported carrier, and can you return a tracking URL for every carrier you do support?
If a vendor cannot answer the normalisation and freshness questions in specific terms, that is informative. A provider that has done the work will enjoy answering them.
So which one should you choose?
Choose the one that performs best on your own tracking numbers, and be suspicious of any other basis for the decision. Carrier counts are self-reported, feature lists converge because features are the easy part, and the differences that cost you support tickets live in normalisation quality and long-tail coverage that nobody publishes.
Ship24 publishes a figure of 2,500 or more courier and 3PL integrations, and like every figure in the table above it is a self-reported claim counted by its own method. Treat all of them as a reason to include a vendor in a trial, never as the reason to select one.
The evaluation matters more than the choice. A team that runs the trial described here will get a good outcome from several of the available providers. A team that picks on carrier count alone can select the strongest vendor in the market and still end up with wrong delivery notifications on the parcels that matter most.
Sources & methodology
- Google Search Central Package tracking specification Primary documentation.
- Universal Postal Union (UPU) Standards programme and catalogue Primary source.
- Universal Commerce Protocol Order capability specification Primary documentation.
- Agentic Commerce Protocol Webhook reference Primary documentation.
