DEV Community: jtalk22

5 Patterns for Handling USPS v3 API Rate Limits (60 req/hour is brutal)

jtalk22 — Tue, 10 Mar 2026 13:43:52 +0000

USPS API Rate Limits: From 6,000/min to 60/hour — What Happened and How to Fix It

USPS replaced their Web Tools XML API with a v3 REST API in January 2026. One thing nobody expected: they dropped rate limits from ~6,000 requests/minute to 60 requests/hour for new applications.

If you're hitting 429s on the USPS v3 API, here's what's actually happening and five architecture patterns to handle it.

What Changed

Old API (Web Tools XML):

~6,000 requests/minute
No formal documentation on limits
Generous in practice

New API (v3 REST):

60 requests/hour (new applications)
5 requests/minute burst
Enforced with HTTP 429

That's a 99% reduction in throughput. A shipping operation doing 1,000 validations/day now needs a fundamentally different architecture.

Why It Happened

USPS's v3 API serves consumer-facing apps (Informed Delivery, etc.) on the same infrastructure. Rate limits protect shared infrastructure. Enterprise shippers get higher limits via the USPS API team, but new applications start at 60/hour.

You can request a rate limit increase through the USPS Developer Portal, but approval takes 2-4 weeks and requires a business justification.

Pattern 1: Response Cache

Most address validation results don't change. Cache responses with a TTL:

import hashlib
import json

def cached_validate(address, cache, client):
    key = hashlib.sha256(
        json.dumps(address, sort_keys=True).encode()
    ).hexdigest()

    cached = cache.get(key)
    if cached:
        return json.loads(cached)

    result = client.addresses.validate(**address)
    cache.set(key, json.dumps(result), ex=86400)  # 24h TTL
    return result

Impact: If 40% of your addresses are repeats (common in B2B), you cut API calls by 40%.

Pattern 2: Request Queue with Rate Smoothing

Don't burst — spread requests evenly across the rate window:

class RateLimiter {
  constructor(maxPerHour = 60) {
    this.interval = (3600 / maxPerHour) * 1000; // ms between requests
    this.queue = [];
    this.processing = false;
  }

  async add(fn) {
    return new Promise((resolve, reject) => {
      this.queue.push({ fn, resolve, reject });
      this.process();
    });
  }

  async process() {
    if (this.processing || !this.queue.length) return;
    this.processing = true;

    const { fn, resolve, reject } = this.queue.shift();
    try {
      resolve(await fn());
    } catch (e) {
      reject(e);
    }

    setTimeout(() => {
      this.processing = false;
      this.process();
    }, this.interval);
  }
}

Pattern 3: Batch Pre-validation

Validate addresses at import time, not checkout time:

Customer uploads CSV of shipping addresses
Background job validates all addresses over hours (staying under rate limit)
Cache results
At label creation time, pull from cache — no API call needed

This works if you have advance notice of addresses (most B2B shippers do).

Pattern 4: Multi-Key Rotation

If you have multiple USPS API credentials (separate business units, departments), rotate between them:

import itertools

keys = itertools.cycle([
    {"client_id": "key1_id", "client_secret": "key1_secret"},
    {"client_id": "key2_id", "client_secret": "key2_secret"},
])

def get_next_client():
    creds = next(keys)
    return USPSClient(**creds)

Warning: USPS terms require each application to have its own credentials. This is only valid if you genuinely have separate applications.

Pattern 5: API Proxy with Built-in Rate Management

If you don't want to build caching and queuing yourself, API proxies handle this at the infrastructure layer. They pool connections, manage token refresh, and smooth rate limits.

I built RevAddress for this exact problem — it's a USPS v3 proxy with 120-600 req/min depending on tier. But you can also build this yourself with Redis + a worker queue.

Request a Rate Limit Increase

The official path:

Log into the USPS Developer Portal
Go to your application → Support
File a service request: "Rate limit increase for [App Name]"
Include: your CRID, current volume, expected volume, business justification
Wait 2-4 weeks

Include actual numbers. "We process 5,000 address validations daily for e-commerce checkout" is better than "we need more requests."

Full article with more code patterns: revaddress.com/blog/usps-api-rate-limits-2026-what-changed

Open-source USPS v3 SDKs: github.com/revereveal/usps-v3

EasyPost March 17 Deadline: Your Migration Options Before Auto-Enrollment

jtalk22 — Tue, 10 Mar 2026 13:43:38 +0000

EasyPost March 17 Deadline: Your Migration Options Before Auto-Enrollment

If you use EasyPost for USPS shipping labels, you have until March 17, 2026 to choose a plan — or get auto-enrolled in BYOCA at $20/month + $0.08/label.

Here's what's happening, what it costs, and your actual options.

What Changed

EasyPost restructured pricing on February 23, 2026. Users who had payment methods on file were auto-enrolled in the BYOCA plan without consent. On March 17, everyone else gets auto-enrolled too.

New EasyPost pricing:

Plan	Monthly	Labels Included	Overage
Free Access (Wallet)	$0	3,000/mo	$0.08/label
BYOCA	$20/mo	3,000/mo	$0.08/label

At 10,000 labels/month, you're paying $0 + $560 in overage = $560/month on EasyPost.

Option 1: Stay on EasyPost Free Access

If you're under 3,000 labels/month, the Wallet plan works. Log into your dashboard and explicitly select "Free Access" before March 17. If you don't choose, you get BYOCA.

Option 2: Go Direct to USPS v3

USPS retired the Web Tools XML API and launched a new v3 REST API with OAuth 2.0. You can talk to USPS directly — no middleman.

The catch: USPS rate-limited the v3 API to ~60 requests/hour for new applications. At scale, you'll need caching, queuing, and rate limit management.

# pip install usps-v3
from usps_v3 import USPSClient

client = USPSClient(
    client_id="your_id",
    client_secret="your_secret"
)

# Validate an address (free, no payment account needed)
result = client.addresses.validate(
    street_address="1600 Pennsylvania Ave",
    city="Washington",
    state="DC",
    zip_code="20500"
)
print(result["address"]["DPVConfirmation"])  # Y = confirmed

Full migration guide: USPS Web Tools to v3 REST: Complete Migration Guide

Option 3: Use a USPS v3 Proxy

If you don't want to manage OAuth tokens, rate limits, and USPS enrollment yourself, API proxies handle the infrastructure.

RevAddress (disclosure: I built this) is one option — flat monthly pricing ($29-$199/mo), no per-label fees, includes address validation + tracking + rate shopping. Also supports BYOK (bring your own USPS keys) if you want to use your own USPS credentials with managed OAuth.

The API is a drop-in replacement:

curl "https://api.revaddress.com/api/address/validate\
?streetAddress=1600+Pennsylvania+Ave\
&city=Washington&state=DC&ZIPCode=20500" \
  -H "X-API-Key: YOUR_KEY"

Cost Comparison

Volume	EasyPost BYOCA	EasyPost Free	Direct USPS	RevAddress Starter
1,000/mo	$20	$0	$0 + infra	$29/mo
5,000/mo	$20 + $160	$160	$0 + infra	$29/mo
10,000/mo	$20 + $560	$560	$0 + infra	$79/mo
50,000/mo	$20 + $3,760	$3,760	$0 + infra	$199/mo

At 10K+ labels, the math is clear. At lower volumes, EasyPost Free or direct USPS works fine.

What I'd Do

If < 3,000 labels/month: stay on EasyPost Free Access. Log in and select it explicitly before March 17.
If you want zero per-label costs: go direct to USPS v3 with the open-source SDK and manage rate limits yourself.
If you need production reliability without USPS rate limit management: use a proxy with flat pricing.

The deadline is real. Don't let March 17 pass without choosing.

Full breakdown with code examples: revaddress.com/blog/easypost-march-17-deadline-migration-options

Open-source USPS v3 SDKs:

Python: pip install usps-v3 (PyPI)
Node.js: npm install usps-v3 (npm)
PHP: composer require revaddress/usps-v3-php (Packagist)