Shipping API Rate Limits: What Every Developer Hits (and How to Fix It)

You've built your multi-carrier integration, it works great in testing, and then Black Friday hits. Suddenly UPS returns 429 errors, FedEx throttles your label generation, and your rate shopping takes 12 seconds instead of 2. Every major carrier API has rate limits — and they're all different.

Carrier Rate Limits You Need to Know

The Token Bucket Pattern

Don't just catch 429 errors and retry. Implement client-side rate limiting so you never hit the wall. Create a rate limiter class that tracks available tokens, refills them at the carrier's allowed rate, and makes callers wait when tokens run out. For USPS, set 5 tokens refilling at 5 per second. For UPS, 20 tokens at 20 per second.

Batch Label Generation

Instead of creating labels one-by-one (which burns rate limit fast), batch them:

Queue incoming label requests for 2-3 seconds

Group by carrier — FedEx labels together, UPS together

Use batch endpoints where available (EasyPost and Shippo both support batch creation)

Process results and map back to individual orders

This turns 200 individual API calls into 3-4 batch requests.

Handling 429 Responses

When you do get rate-limited, respect the Retry-After header. Some carriers include it, others don't. If present, wait that many seconds. If not, use exponential backoff capped at 30 seconds.

Peak Season Strategy

During November-December, carrier APIs get slower and stricter. Pre-generate labels during off-peak hours (2-6 AM EST), cache rate quotes for 15-minute windows, and have a fallback carrier ready if your primary throttles you.

See how Atoship handles rate limits automatically →