Carrier API Rate Limits in 2026: 12 Platforms Compared

If you are sizing a token bucket for a carrier adapter, the number that matters is not the one in the vendor's marketing page. It is the number in the rate-limit doc, dated, and ideally reproduced by someone who has actually been throttled. This post collects the published carrier API rate limits for 12 parcel carrier and multi-carrier platforms as they stood on 22 July 2026, with a source for every figure. Where a vendor does not publish one, it says so. Nothing here is estimated.

Why these numbers belong in your capacity model

Retry/backoff sizing, token-bucket configuration, and multi-tenant fair-share allocation all depend on knowing the real ceiling per carrier, not an assumed shared one. The headline case this year is USPS. Its legacy Web Tools XML API had no enforced throttle and integrators observed sustained throughput of roughly 6,000 requests per minute with no 429 responses. On 25 January 2026, USPS retired that API and moved everyone to v3 REST, where the default is 60 requests per hour. That is not a tuning adjustment. It is a ceiling that moved by three orders of magnitude overnight, in a production dependency most shippers treat as background infrastructure.

Method and scope

Every figure below comes from a carrier or platform's own developer portal, official docs, or an open GitHub issue where the vendor itself has left the question unanswered. Data was collected on 22 July 2026. Limits shown are default, publicly documented tiers; most vendors offer negotiated increases through support tickets, which are not reflected here because they are not publicly quoted figures. This comparison does not cover per-endpoint variations beyond the headline endpoint, negotiated enterprise contracts, or freight/LTL carrier APIs. Where the field says "Not published," that is a documented absence, not an estimate.

The comparison table

Two DHL sub-products worth flagging separately: the Shipment Tracking - Unified API starts new integrators at a service level allowing 250 calls per day, with a maximum of 1 call every 5 seconds, a limit intended for initial development and not suitable for production use. The Location Finder - Unified API defaults to 500 calls per day with a spike arrest of 1 call per second when first added to an app. Both are upgradeable on request, but the starting tier is what breaks a naive sandbox-to-production migration.

What the spread tells you about designing for the worst carrier, not the best

Line up DHL's 15 requests/second against USPS v3's 60 requests/hour and you get roughly 0.017 requests/second. That is a gap of nearly three orders of magnitude between two carrier adapters that might sit in the same multi-tenant router, behind the same shipping label endpoint, serving the same checkout flow. Treat all carrier adapters as equally elastic and the USPS adapter alone will starve a shared queue while DHL, FedEx, and the rest still have headroom.

The practical fix is not clever. It is per-carrier token buckets, sized to the worst-published ceiling for that carrier, not an average across your carrier mix. A few things follow from that:

• Size the USPS bucket to 60 tokens/hour and refill on a strict rolling window, because direct USPS v3 access is capped at 60 requests/hour, not per minute, and burst refills will get you throttled immediately.
• Size the FedEx bucket around the 10-second window, since each project has a transaction rate limit of 1,400 transactions per 10 seconds, with throttling applied if transactions exceed this limit during that timeframe.
• Treat UPS as unknown by design. The open UPS-API GitHub issue asking whether REST rate limits are documented at all has sat unanswered since 2023, so any bucket size you pick for UPS is a guess dressed up as a config value. Set it conservatively and monitor 429 rates as your real signal.
• Do not average carrier limits into one "shared carrier pool" setting. A router that pools DHL's 15 req/sec with USPS's 0.017 req/sec into a blended average will overshoot USPS constantly and undershoot DHL needlessly.

OAuth token lifetime as a hidden constraint

Token TTLs are the quieter half of this problem, and they interact badly with tight rate limits when refresh calls themselves consume quota. Of the platforms surveyed, only two publish a clear TTL: FedEx states an OAuth token is valid for an hour, and USPS v3 issues tokens valid for 8 hours via client_credentials grant. Every other platform in the table above leaves TTL undocumented publicly, which means you find out empirically, usually via an unexpected 401 mid-shift.

The practical guidance here is unglamorous but works: cache tokens against their actual TTL rather than a guessed default, add jitter to the refresh so a fleet of workers does not hammer the token endpoint in the same second, and monitor 401-after-retry as a distinct alert from 429. A 429 tells you the bucket is full. A 401 after a retry usually tells you the token expired mid-request-burst, which is a different failure mode and needs a different fix (refresh-ahead, not backoff).

Where the data runs out, and what to do about it

UPS, Shippo's headline figure, and most multi-carrier TMS platforms, including Cargoson, nShift, Sendcloud, and ClickPost, do not publish a single rate-limit number. That is normal for platforms whose limits are account-negotiated rather than tiered publicly, and it is not a signal that the limit does not exist. Treat "Not published" as "ask your account manager for the number in writing and put it in your runbook," not as license to assume unlimited throughput. An unlimited-until-proven-otherwise assumption is exactly how a Black Friday label storm turns into an incident report.

If you operate a multi-tenant carrier router, the next step is mechanical: pull this table into your capacity spreadsheet, mark every "Not published" row as a support ticket to file this quarter, and size your token buckets to the worst confirmed number per carrier, not the best. Re-check the USPS and DHL rows in particular. USPS has already moved once this year, and DHL's quota-upgrade process is a manual request, not a self-serve toggle, so the number you get depends entirely on when you asked.