USPS API Access Control: What April 1, 2026 Actually Changed

On April 1, 2026, USPS changed how tracking data is reached. Package tracking had always been possession-based: hold a valid tracking number and an API key, get the events. Access Control replaced that with an identity-based model, where the calling application has to be registered and authorized for the Mailer ID that owns the shipment.

USPS announced the initiative months ahead with a portal banner naming the month and nothing else. No scope names, no enrollment steps, no endpoint list. The specifics arrived with the switch.

This page records what landed, who it reached, and how the same governance program produced the Addresses API license that took effect on August 1.

The model shift, in one line

Before: you have the tracking number, you get the data. After: your application is authorized for the Mailer ID that owns the shipment, or you do not.

Everything else follows from that sentence. MID linking is how authorization is proven. The service-provider classification exists because the two sides of that line behave differently. Bulk feed restrictions exist because a bulk feed is the possession model at scale.

What each endpoint got

Endpoint	Before April 2026	After
GET /addresses/v3/address	OAuth only	Unchanged by Access Control. Separately moved to a signed license on August 1, 2026
GET /tracking/v3/tracking/{id}	OAuth only	Mailer ID authorization enforced
POST /prices/v3/total-rates/search	OAuth only	Unchanged
POST /labels/v3/label	OAuth plus payment authorization	Unchanged by Access Control; still requires USPS Ship enrollment and an Enterprise Payment Account
GET /service-standards/v3/estimates	OAuth only	Unchanged
Bulk tracking feeds and webhook subscriptions	Available	New authorization requirements

The pattern in that table is worth naming: Access Control was a tracking rule, not an API-wide one. Teams that only validate addresses and buy labels saw nothing change on April 1. Their disruption came four months later, from a different USPS office and a different mechanism.

Who it reached

Restricted. Third-party logistics and fulfillment providers tracking on behalf of merchants. Software platforms (Shopify apps, warehouse systems, shipping aggregators) pulling tracking through the API. Data aggregators extracting events in bulk. Any integration tracking across Mailer IDs it does not own.

Untouched. Direct shippers tracking shipments they mailed themselves. Consumers on usps.com. Address validation, pricing, service standards, and label creation.

The dividing question is short: does your application read tracking for packages mailed by someone other than the credential holder? Yes puts you on the restricted side. No leaves you where you were.

The open questions, answered

The March 2026 version of this page listed what USPS had not published. Those questions have answers now, and the answers are the useful part of this record.

Open question, March 2026	What happened
Exact enforcement date	April 1, 2026
What the authorization model becomes	Possession-based to identity-based, keyed on the Mailer ID that owns the shipment
Whether bulk feeds are restricted differently	Yes. Bulk extracts and webhook subscriptions picked up their own authorization requirements
Whether a grace period applies	None was published. The switch landed on the announced month’s first day
Whether direct shippers are affected	They were not. The direct-shipper and service-provider split held as described

One further change arrived alongside the initiative and gets less attention than it deserves: application configuration moved into the Customer Onboarding Portal. Every onboarding step USPS documents today routes through COP: creating the business account, creating the app, retrieving the consumer key and secret. If your mental model of the Developer Portal predates April, it is out of date, and the app you configured under the old flow is not necessarily configured under the new one.

A practical corollary. The portal’s own app badge is a summary, and a summary can disagree with the gateway. The test that settles it is a token request: if the OAuth endpoint returns a token for your consumer key, the app works. If it returns app_not_approved, the app does not work, whatever the badge says. Check the endpoint, not the badge.

Where this led

Access Control was not a one-off tracking rule. It was the visible front of a governance program, and the office that ran it, USPS’s Addressing Access Control team, is the same office that started issuing Addresses API license notices two weeks later.

The sequence, as it played out:

Jan 25, 2026   Web Tools XML retired. v3 REST + OAuth 2.0 required.
Apr  1, 2026   API Access Control. Tracking moves to Mailer ID authorization.
               App configuration moves into the Customer Onboarding Portal.
Apr 15, 2026   First notices: the current Addresses API is discontinued
               July 12 unless you accept new terms, sign a license
               agreement, and pay a consumption fee.
Jul 15, 2026   Cutover postponed to August 1. Signed licenses take effect
               that day.
Aug  1, 2026   Addresses API fee schedule in force. Access requires a
               signed license and a funded Enterprise Payment Account.

Read as a series, the direction is unambiguous: USPS is moving every API surface from open access to per-identity, per-credential, metered access. Tracking went first because tracking data was the security argument. Addresses went second because addresses were the volume. The fee curve, the license terms, and the enrollment sequence are covered in what the USPS API actually costs.

What identity-based access means for platform builders

If authorization is keyed to the Mailer ID that owns a shipment, then the credential a request travels on determines what that request can read. That makes credential architecture a product decision rather than a deployment detail.

Running every merchant’s traffic through one platform credential means one application must be authorized for every Mailer ID it touches, and the platform carries the service-provider classification. Running each merchant on their own USPS credentials means each merchant is authorized for their own Mailer IDs, and each is a direct shipper from the Postal Service’s point of view.

That second shape is BYOK, and it is how RevAddress works at every plan. The credential payload carries the fields the regime actually asks about:

POST https://api.revaddress.com/api/byok/credentials
X-API-Key: rv_live_your_key_here
Content-Type: application/json

{
  "client_id":     "merchant-usps-consumer-key",
  "client_secret": "merchant-usps-consumer-secret",
  "crid":          "merchant CRID",
  "master_mid":    "merchant master Mailer ID",
  "label_mid":     "merchant label Mailer ID",
  "epa_account":   "merchant Enterprise Payment Account"
}

→ 201 Created
{
  "merchant_id":        "...",
  "status":             "verified",
  "has_payment_fields": true,
  "message": "Credentials verified — your USPS tokens are now managed separately."
}

Credentials are encrypted at rest with AES-GCM under per-merchant derived keys, and each merchant gets an isolated token lifecycle, their own rate-limit budget, and their own Mailer ID scope. A stored credential that fails its OAuth check comes back as pending_verification rather than silently appearing to work. Check GET /api/byok/status before you route production traffic through it.

The other lever is the one nobody enjoys: the 60-requests-per-hour default is shared across every endpoint your app calls. Authorization overhead does not get its own budget. The rate limit guide covers caching, queue smoothing, and how to ask USPS for more.

Start here

• The architecture that survived both waves — what to build so the next governance change is a config edit
• CRID and MID enrollment, step by step — how Mailer ID linking actually gets done
• USPS API pricing and the August license — the fee curve and the signature sequence
• Connect your own USPS license from the dashboard — free key, 1,000 requests a month, no card

Sources

• USPS, Getting Started, checked August 23, 2026. The Customer Onboarding Portal flow, the default product list including Tracking, the Labels enrollment requirement, and the quota-increase route are published there.
• John M. Kuchta, “USPS Access Control: How (Not) to Deprecate a Public API”, April 2, 2026 — the April 1 switch date, the possession-to-identity framing, and the affected-party breakdown.
• USPS, Addresses API Tech Sheet, fee schedule effective August 1, 2026, published August 13, 2026.