Carrier API Rate Limits Across 9 Providers, 2026

Nine carrier and multi-carrier shipping APIs. Nine different answers to "how many requests can I send before I get throttled?" Some publish the number in bold on their docs homepage. One carrier has a developer publicly asking for the figure in a GitHub issue and getting no answer. This post pulls every published carrier API rate limit we could find as of August 13, 2026, and marks the rest "Not published" rather than guessing.

Why rate-limit numbers, not vendor claims, matter for integration design

Retry and backoff logic is only as good as the ceiling it's designed against. If you build exponential backoff assuming a per-second limit but the carrier actually enforces a daily quota, your batch job fails at 2am instead of gracefully queuing. This is a data table, not a load test: we did not generate synthetic traffic against production endpoints. Every figure below traces to an official developer portal page, checked on the date stated. Where a vendor doesn't publish a number, the table says exactly that.

Method

We pulled figures from official developer documentation only, checked August 13, 2026. That excludes negotiated enterprise quota increases, region-specific variations, and SLA-tier custom limits, all of which exist but aren't publicly documented in a way we can cite. The rule is simple: if a vendor doesn't publish a number, the cell reads "Not published." No estimates, no extrapolation from forum posts, no "typically around X."

The table

Multi-carrier platforms like ShipEngine, Shippo, Easyship, EasyPost, nShift, Sendcloud and Cargoson each abstract carrier-side limits differently. Some pass the underlying carrier's quota straight through to you; others apply their own ceiling on top, regardless of what the carrier allows. That distinction matters more than the raw number when you're designing a queue.

Direct carrier APIs — what's actually documented

FedEx is the most transparent of the direct carriers here. Its docs state that quotas, rate limits, and thresholds are in place to allocate FedEx resources effectively and efficiently, and the default Per Capability Per Project quota for the Track capability is 100,000 requests per day.

DHL splits its limits by product and by access tier. For Shipment Tracking, a new integration gets a service level allowing 250 calls per day, with a maximum of one call every 5 seconds, and DHL is explicit that this tier is for initial development, not production. Location Finder ships with a higher ceiling: it comes automatically with a 500 calls per day quota and a spike arrest of 1 call per second. The MyDHL Express test environment caps out separately, at 500 service invocations per day for your access credentials in test.

UPS is the outlier. A developer directly asked whether rate limits are published for the REST API, having already checked the documentation and FAQ, and found no specifics in the UPS API documentation GitHub issue tracker. If you've seen a number quoted for UPS elsewhere, treat it as unverified. It didn't come from UPS's own docs.

Multi-carrier and aggregator APIs

ShipEngine draws the sharpest sandbox/production gap on this list. Its docs confirm the sandbox environment has a 20 requests per minute rate limit, significantly lower than production, where the default climbs to up to 200 requests per minute. That's a 10x jump the moment you go live, so load-test in sandbox and you'll get a false sense of headroom.

Shippo doesn't give you one number to remember. Its documentation notes rate limits differ depending on the endpoint and HTTP verb, with all limits measured per minute. If you're hardcoding a single throttle value for Shippo across your integration, you're guessing at the wrong granularity.

Easyship publishes the cleanest side-by-side production/sandbox split of the group. Production allows 60 requests per minute and 10 requests per second across all endpoints, dropping to 6 requests per minute and 1 request per second in sandbox mode.

EasyPost uses a flat per-second model rather than per-minute. It enforces a rate limit of five requests per second across Index endpoints, and exceeding it triggers a 429, with a separate dynamic, load-based limiter applied to buying and rating calls. That second limiter is the one that catches people off guard, since it isn't a fixed number you can code against.

Across the multi-carrier category, ShipEngine, Shippo, Easyship, EasyPost, nShift, Sendcloud and Cargoson each take a different throttling philosophy: fixed requests-per-second, per-minute buckets, or dynamic load-based ceilings. The raw number matters less than knowing which model you're dealing with before you write your retry loop.

What the gaps tell you

UPS's silence on this is itself a data point. If a carrier won't publish a ceiling, you have to assume it exists anyway and build wider backoff margins than you would for FedEx or EasyPost, where the number is printed on the page.

DHL's daily-quota model behaves differently under failure than a per-second model. A batch job that trips a DHL daily cap at 3pm doesn't recover until the quota resets, whereas a FedEx or EasyPost per-second limit clears within moments once you back off. If you're running nightly batch tracking updates against DHL's 250-or-500-call daily tiers, one bad retry storm can lock you out for the rest of the day. Design your retry strategy per provider, not as one generic algorithm.

None of this confirms that published ceilings match observed behavior under real load. A useful follow-up test: run controlled request bursts against sandbox environments for each provider and log exactly where the 429s start firing, then compare that against the documented number.

Limitations and what we couldn't verify

USPS, GLS, DB Schenker, nShift, Sendcloud and Cargoson don't publish a standalone numeric rate-limit page as of this check. We're marking all of them "Not published" rather than inferring a figure from support tickets or third-party blog posts. If you've got a documented number for any of these, from an official source, we'd genuinely like to see it and correct the table.

Next step for your team: pull this table into your integration spec, mark which provider uses which throttling model, and size your queue depth and backoff intervals against the specific unit (per-second, per-minute, per-day) rather than a single global assumption.