USPS Tracking API, by the numbers: Pricing, terms, and how it compares
Earlier I wrote about how USPS rolled out its API Access Control initiative without much advance communication. That post was about the rollout and how USPS has effectively killed free API access for package recipients.
This post is about what’s required to regain API access to USPS tracking data on the recipient side — for individual recipients, or for applications acting on their behalf. I’ve independently obtained a copy of the USPS IP Agreement that such developers must sign to get there, and I’ve exchanged email with USPS to clarify a few of the more ambiguous terms. Here’s what I found.
What changed, in one paragraph
Before April 1, if you had a USPS tracking number, you could look up its status through the API. Possession of the tracking number was enough. Web Tools registration was loose, the API didn’t gate queries by who owned the package, and the practical result was that any developer building a recipient-side application — anything that helps people track packages addressed to them — could just call the API and get back tracking events. After April 1, that path is gone. To retrieve tracking events programmatically, your application must now be authorized for the Mailer ID (MID) that owns the label — the identifier USPS assigns to the business that bought the postage. Recipients don’t own MIDs. Apps that track on behalf of recipients don’t own MIDs either. The consumer-facing channels — usps.com and the USPS mobile app — still work, but the API path that powered third-party recipient-side tracking is closed. The only way back in is a commercial contract with USPS for Tracking Data Services, starting at $599 per month.
The pricing, in context
This post is about API access for recipient-side tracking — applications that track packages on behalf of the people receiving them, not the businesses shipping them.
The USPS tiers, specifically
The effective per-call rate at the top of each tier is:
- Tier 1 at 100,000 calls: $599 ÷ 100,000 = $0.00599 per call
- Tier 2 at 1,000,000 calls: $5,499 ÷ 1,000,000 = $0.0055 per call
- Tier 3: $0.005 per call
The lowest-volume users pay the highest per-call rate. At one call per month, the effective rate is $599 per call. The transition from Tier 1 to Tier 2 is a cliff, not a slope. At 100,000 calls you pay $599; at 100,001, you pay $5,499. One additional call costs $4,900 — a 9.18× jump for crossing a single-call boundary. There is no graduated overage rate.
So, what’s the easiest, cheapest way to get tracking events from each carrier if you didn’t actually ship the package?
Direct carrier APIs
USPS is a major outlier when it comes to direct API access.
Third-party carrier aggregator APIs
Outside the carrier APIs, third-party aggregators serve the same recipient-side use case by re-exposing carrier tracking data through their own APIs. Their pricing is much closer to industry norms:
Four things stand out from this comparison:
1. FedEx’s free daily quota for the Track API is 100,000 calls per project per day. USPS’s Tracking Data Services entry tier gives you 100,000 calls per month for $599.
FedEx, free, gives you 30× the volume of USPS, paid. Per project. Per day. The same volume of tracking events for which USPS now charges $599/month is available from FedEx for free, at 30 times the cap.
2. UPS publishes no volume cap on its Track API at all.
The OpenAPI spec on UPS’s GitHub doesn’t mention rate limits anywhere. The Developer Kit FAQ says “UPS Tracking API is free to license. There [are] no hidden fees or charges.” UPS appears to enforce account-level blocks for suspected abuse — there’s a “Blocked Merchant” 403 in the spec — but no documented volume threshold that would catch a well-behaved consumer application.
3. Access Control broke from peers and USPS’s own past.
Web Tools was free, registration was loose, and recipient-side developers could query tracking events without owning the packages. The new regime is the only one of its kind among major US carriers: a paid commercial tier for the use case that everyone else still gives away.
4. USPS is the only one with a non-cancellable contract.
UPS and FedEx Track APIs are free; there’s nothing to cancel. Tracking aggregators like Shippo and 17TRACK bill per call or per quota with no commitment. Even AfterShip¹, the closest paid analog among aggregators, is month-to-month. USPS locks licensees in for a year with no cancellation path at all.
The contract
The clauses that stand out are:
§2.4 — Unilateral modification. USPS can change the license terms at any time by posting updated terms at developers.usps.com. Continued use constitutes acceptance. No notification, no version pinning, no grandfathering.
Get John M. Kuchta’s stories in your inbox
Join Medium for free to get updates from this writer.
§3.7(d) — No competing services. Licensees may not use the Services “to offer a competing service to the Services.” The literal reading is broad enough to cover almost any application that displays tracking events, so I wrote to USPS asking whether the intent was narrower — specifically, whether the clause was meant to prevent reselling raw USPS tracking data as a standalone product. The response from the Tracking API team:
Regarding section 3.7(d) your reading/understanding of that section is correct.
So the clause isn’t intended to be taken as broadly as it’s written.
§4.1 — Non-cancellable term. “The Agreement is not cancellable and shall remain in effect until it expires or is earlier terminated according to its terms.” The Initial Term runs from signing; maximum Term is two years. §4.3.3 adds that if the licensee terminates for any reason — including USPS materially breaching the agreement — there is no pro-rata refund of prepaid fees.
§11 — Audit rights. USPS may audit a licensee’s Tracking API usage for two years after the agreement ends. The audit is at USPS’s expense unless it uncovers “material non-compliance,” which the agreement does not define.
§12.9 — Confidentiality of pricing. Licensees agree to hold the terms, pricing, MID authorizations, and credentials “in confidence.” Because I haven’t signed the agreement, this clause doesn’t bind me² — which is why you’re reading this post at all. But anyone who does sign is prohibited from discussing their pricing deal, even if it’s identical to the standard one furnished to me. This is speculation, but: confidentiality clauses typically exist to protect pricing asymmetries, not uniform pricing. If every developer were paying the same price, there’d be nothing to keep confidential.
The contract version date
At the bottom of the License Agreement, in italics, I found:
Version — 3/30/2026
So — the license developers must sign to restore their Tracking API access was revised as recently as March 30, 2026. Since enforcement began on April 1, USPS finalized the terms two days before they took effect.
USPS can still fix this
USPS has said that one of its goals with the Access Control initiative is to prevent fraud and abuse of tracking data, and that’s worth supporting. However, small developers need not be collateral damage for fraud prevention efforts.
If I were a Product Manager behind the USPS API, I’d consider one or more of the following strategies instead of the current $599/month barrier to entry. Each of these is grounded in something USPS or its peers already do:
1. Require identity verification for developers
IRS, SSA, CBP, DHS, and other federal agencies already use ID.me and Login.gov for authentication and identity verification. USPS — also a federal agency — runs its own separate login system instead. If USPS adopted ID.me or Login.gov for the developer portal, it would tie each developer account to a single verified real person, which mitigates most forms of free-tier abuse outright. This idea makes achieving USPS’s fraud-prevention goal easier rather than harder, whereas most other ideas depend on USPS being willing to trade some abuse-prevention strictness for developer access. Scammers hate identity verification.
2. Limit the number of labels that can be tracked for free
Give developers a small free allowance — say, 100 tracked labels per month, in line with what 17TRACK already offers — and charge for usage above that. Most small developer use cases would fit comfortably under such a cap, and the cap itself makes free access hard to weaponize, especially in combination with identity verification (see 1, above).³
3. Offer a recipient-authorized access pattern
Package recipients have a right to their data; the access method shouldn’t matter.
Let USPS account holders use an OAuth 2.0 flow to authorize an application to access tracking events for packages addressed to their registered address(es), at low-to-no cost. The developer only gets API access to tracking events for the labels bound to a verified recipient’s address — no broader access, no abuse vector. USPS already runs the consumer infrastructure for this in the form of Informed Delivery; exposing the same consent model as an OAuth flow would unlock an entire class of legitimate consumer applications at essentially no cost to USPS.
These aren’t radical proposals. They’re how the rest of the federal government, the rest of the shipping industry, and the rest of the API industry already work.
What I wouldn’t do
Pure pay-as-you-go plans can work well if they are label-based (see 2, above). Shippo and EasyPost both offer (relatively) unlimited requests at $0.02 per label tracked. However, a request-based model (like FedEx’s) really doesn’t serve USPS’s stated concerns around fraud and abuse, because:
- 100,000 free requests per day is enough to spy on 100,000 different tracking numbers, and
- It’s easy for legitimate applications to create tens of thousands of API requests for a small number of labels.
Take an application that polls for a label’s tracking events once every five minutes. That’s 12 requests per hour, 288 requests per day and about 8,760 requests per month. Under FedEx’s regime, that’s completely and comfortably free.
But for USPS, the same usage costs $1.44 per day and $43.80 per month — and that’s the cheapest USPS can be, available only to applications already paying $65,988 annually for the 1M+ request tier (see USPS pricing tiers above).
Even if USPS eliminated the minimum monthly spend, eliminated the annual commitment, and let everyone have the $0.005/request rate, tracking 100 packages would still cost an eye-watering $4,380.48 every month. That math doesn’t math for a small developer. Such a regime would almost necessarily require a generous free allotment (like FedEx’s 100,000 free per day per project) and then you’re back to the abuse problem USPS wants to avoid.
Hope for the future?
I asked USPS about the existence of other, potentially unpublished usage tiers in the same email exchange as above, and the official response was:
Currently that is the only tiered pricing we have.
“Currently” is not a promise of any kind, but it could signal that there is some internal discussion about different tiers that could be offered in the future. One can only hope that USPS wants to fix this.
Footnotes
¹When AfterShip moved its Tracking API behind a paid tier (originally $99/month, now $119), the Home Assistant project and other open-source integrators pushed back publicly — at a price point a fraction of USPS’s $599 floor.
²§12.9 binds executed licensees to confidentiality on pricing and terms. This post is based on an unsigned quote (Order Form 2026–0219) I received for evaluation but did not execute. The clause cannot bind prospective customers reviewing a quote.
³17TRACK’s free tier covers up to 100 labels per month. As of April 1, 2026, it’s unclear whether USPS labels still count toward this tier — 17TRACK hasn’t published how they handle billing for USPS tracking post-Access Control, but they’ve told customers to expect “billing changes” for “off-chain” tracking (i.e., tracking as a non-shipper).
