USPS April 2026 Access Control: The Architecture That Survived It

Most teams treated the January 2026 Web Tools retirement as a one-time migration. Move XML to JSON, swap the User ID for OAuth, update the hostnames, done.

It was not one time. Access Control followed on April 1 and rewrote tracking authorization. The Addresses API license and its fee schedule followed on August 1. Three breaking changes in seven months, from three different requirements, hitting three overlapping sets of integrations.

The teams that absorbed all three had one thing in common, and it was not foresight about any particular rule. It was where their USPS calls lived. This page is about that, and about the checks worth running if you have not looked since spring. The endpoint-level record of what Access Control did is in what April 1 actually changed.

What the three waves each demanded

No single architectural choice anticipated all three. What survived them was the shape of the integration, not a prediction about its content.

Coupling is what made it expensive

A USPS integration that grew organically looks like this: a validation call in the checkout controller, another in an address utility, a rate call in the shipping service, a tracking poll in a cron job. Four files, four sets of error handling, four places that hardcode a hostname.

Each wave then costs four edits, four test passes, and one file somebody forgets.

The same integration behind a single client is one edit per wave. That is the entire argument, and it is unglamorous enough that it usually loses to shipping the feature. Three waves in seven months is what changes the arithmetic.

Scattered                          Consolidated
─────────────────────────          ─────────────────────────
controllers/checkout   → USPS      controllers/checkout  ┐
services/shipping      → USPS      services/shipping     ├→ usps_client → USPS
utils/address          → USPS      utils/address         │
cron/tracking          → USPS      cron/tracking         ┘

Per policy change:                 Per policy change:
  4 files, 4 test passes             1 file
  1 you forget

Three shapes that absorbed the waves

A client library behind a thin wrapper. The open-source usps-v3 SDKs handle the OAuth lifecycle, token refresh, and retry behavior, which is where two of the three waves actually landed. Wrap the SDK in one service class so your application calls your vocabulary, not the SDK’s, and an SDK upgrade stays inside the wrapper.

pip install usps-v3
npm install usps-v3

A managed API in front of USPS. Route USPS traffic through a layer that absorbs upstream changes on your behalf. The OAuth lifecycle, rate-limit budgeting, caching, and retries stop being yours to maintain. This is what RevAddress is; it is also what EasyPost, Shippo, and ShipEngine are, with a different trade. The comparison covers who charges what and in which unit.

Per-merchant credentials. Under identity-based access, the credential a request travels on decides what the request may read. One shared platform credential concentrates every merchant’s authorization burden on a single application. Separate merchant credentials distribute it, and each merchant presents to USPS as themselves.

That third shape is BYOK, available on every RevAddress plan including Free. Credentials are AES-GCM encrypted at rest under per-merchant derived keys, each merchant gets an isolated token lifecycle and their own rate-limit budget, and the stored payload carries the CRID and Mailer ID fields the current regime asks about. The full request and response shape is in the April 1 record.

None of the three is exotic. All three share the property that matters: the change lands in one place.

Checks worth running now

If your integration has not been examined since spring, these are the five that surface real problems.

1. Confirm your Mailer IDs are linked in the Customer Onboarding Portal. Since April, app configuration lives at cop.usps.com, and Mailer ID linkage is what authorizes tracking reads. An app configured before the move is not automatically configured after it. The CRID and MID enrollment guide walks the whole sequence.

2. Test your app with a token request, not the portal badge. The Developer Portal’s app status is a summary. The gateway is what serves your traffic. Request an OAuth token with your consumer key: a token means the app works, and app_not_approved means it does not, whatever the badge shows. This is a ten-second check that has caught more than one integration that believed it was healthy.

3. Classify your own tracking usage. Count the Mailer IDs your application reads tracking for, and how many of them you own. All of them means you are a direct shipper and Access Control never applied. Any of them belonging to clients means you are on the restricted side and the linkage in check 1 is load-carrying.

4. Confirm the Addresses license and a funded payment account. This is the August 1 wave, not the April one, and it catches teams who thought they were clear because Access Control missed them. Address validation now needs a signed license agreement and an Enterprise Payment Account with money in it; the fees debit monthly for the prior month’s usage. The pricing guide has the curve and the signature sequence.

5. Budget against 60 requests an hour. The default limit is per application and shared across every endpoint, so authorization overhead and address lookups compete for the same window. Increases come from a service request on the USPS Email Us page, and they take days rather than minutes. The rate limit guide covers caching and queue smoothing, which help more than a higher ceiling usually does.

The direction, stated plainly

Three waves in one year, each moving the same way: from open access toward access that is tied to an identity, scoped to a credential, and metered.

Tracking went first because tracking data carried the security argument. Addresses went second because addresses carried the volume. Nothing USPS has published names a third target, so treat the direction as a trend and not a schedule.

What follows from it is a build rule rather than a prediction. Assume the next change will be about whose credential a call uses or how much that call costs, because both of the 2026 changes were. Then make sure a credential rule and a metering rule are each one edit in your codebase. That is a smaller commitment than it sounds, and it is the difference between the next USPS notice being a Tuesday afternoon and being a sprint.

Start here

• What April 1 actually changed — endpoint-by-endpoint, plus the BYOK credential contract
• CRID and MID enrollment — the linkage check 1 depends on
• USPS API pricing and the August license — the fee curve and the signature sequence
• Get a free API key — 1,000 requests a month, no card, BYOK on every plan

Sources

• USPS, Getting Started, checked August 23, 2026 — the Customer Onboarding Portal flow, the default product list, and the quota-increase route.
• John M. Kuchta, “USPS Access Control: How (Not) to Deprecate a Public API”, April 2, 2026 — the April 1 switch date and the scope of the tracking change.
• USPS, Addresses API Tech Sheet, fee schedule effective August 1, 2026, published August 13, 2026.