USPS Web Tools Shutdown 2026: What Broke and How to Migrate

On January 25, 2026, USPS pulled the plug on Web Tools — the XML API that has powered USPS integrations for over two decades. Every request hitting secure.shippingapis.com now returns an error. Every plugin, module, and custom integration built against that API is broken.

This post covers exactly what happened, which systems are affected, what the replacement looks like, and how to migrate.

What happened

USPS Web Tools was a free XML/HTTP API launched in the early 2000s. You registered for a USERID, constructed XML request bodies, and POSTed them to https://secure.shippingapis.com/ShippingAPI.dll. The API handled address validation, rate calculations, tracking lookups, label printing, and more — all via XML over HTTP.

USPS announced the deprecation in Q3 2024. The v3 REST API launched in parallel during 2025, giving developers roughly a year to migrate. On January 25, 2026, the legacy endpoints went dark.

Any code that still references secure.shippingapis.com or constructs XML request bodies with a USERID parameter is now dead.

What broke

The shutdown hit a wide surface area. Here are the systems with confirmed breakage:

WooCommerce USPS Shipping Method plugin — The official and third-party WooCommerce USPS plugins (including the popular one from WooCommerce.com) used Web Tools for live rate calculation at checkout. Sites running unpatched versions display no USPS shipping options, or throw fatal errors during checkout. See our WooCommerce USPS migration guide for the exact fix.

Magento built-in Magento_Usps module — Adobe Commerce and Magento Open Source ship with a native USPS module. It hard-coded Web Tools endpoints. Adobe tracked this as AC-15210. Any Magento store using the built-in USPS carrier is affected unless the patch has been applied. See our Magento AC-15210 fix guide.

Stamps.com legacy integrations — Third-party apps that integrated with Stamps.com’s old API layer (which itself proxied Web Tools in some configurations) may have inherited breakage. Direct Stamps.com accounts are unaffected — their internal migration was handled on their end.

ShipStation legacy connections — ShipStation’s USPS connection type has multiple modes. The “direct USPS” connection mode that used Web Tools credentials was deprecated. Stores using ShipStation’s carrier-branded labels through their platform are unaffected; only direct USPS connections through the legacy mode broke.

Custom integrations hitting secure.shippingapis.com — Any in-house code that directly calls the old endpoint is completely broken. This includes:

• PHP scripts using file_get_contents() or cURL to call ShippingAPI.dll
• Python scripts using requests or urllib to POST XML to the legacy URL
• Node.js integrations using axios, fetch, or got against the old endpoint
• Ruby, Java, .NET, and any other language making HTTP calls to secure.shippingapis.com

osCommerce and OpenCart USPS shipping modules — Both platforms shipped USPS modules that called Web Tools directly. These modules are not actively maintained for most legacy versions. Stores on osCommerce 2.x or OpenCart 2.x are almost certainly broken without manual patching.

Any rate-shopping or address-cleansing middleware — Internal tools, ETL pipelines, address hygiene workflows, and fulfillment middleware that hit the old API for address standardization or rate lookups are all affected.

The replacement: USPS v3 REST API

USPS replaced Web Tools with a proper REST API. The architecture is fundamentally different:

Authentication: Web Tools used a USERID query parameter — a plaintext identifier tied to your registration. The v3 API uses OAuth 2.0 client_credentials flow. You exchange your client_id and client_secret for a Bearer token, and that token goes in the Authorization header of every request. Tokens expire and must be refreshed.

Data format: Web Tools was XML in, XML out. The v3 API is JSON throughout. No more constructing XML request bodies or parsing XML responses. Standard JSON serialization/deserialization.

HTTP methods: Web Tools used POST for almost everything, with the operation name encoded in XML or a query parameter. The v3 API is RESTful: GET for lookups, POST for creates, DELETE for cancellations. Operations map to HTTP verbs and URL paths.

Rate limits: Web Tools had no meaningful rate limit for most operations. The v3 API enforces 60 requests per hour by default for address validation. This is the biggest operational change for high-volume users. The limit is requestable for increase — submit a request to USPS at emailus.usps.com. For tracking and rates, limits vary by endpoint. See our rate limit guide for the full breakdown.

Registration: You still register for free at developers.usps.com. A developer account gets you OAuth credentials for the non-commerce endpoints (address validation, tracking, rates, service standards). Label printing requires a separate Payment Authorization process through USPS Business Customer Gateway.

Cost: Still free. USPS does not charge for API access.

Endpoint mapping

Here are the eight most critical Web Tools endpoints and their v3 equivalents:

A minimal address validation call in the old API looked like this:

POST https://secure.shippingapis.com/ShippingAPI.dll?API=Verify&XML=
<AddressValidateRequest USERID="YOURUID123">
<Address ID="0">
  <Address1></Address1>
  <Address2>1600 Pennsylvania Ave NW</Address2>
  <City>Washington</City>
  <State>DC</State>
  <Zip5>20500</Zip5>
  <Zip4></Zip4>
</Address>
</AddressValidateRequest>

The same call in v3:

curl "https://api.usps.com/addresses/v3/address?streetAddress=1600+Pennsylvania+Ave+NW&city=Washington&state=DC&ZIPCode=20500" \
-H "Authorization: Bearer YOUR_OAUTH_TOKEN"

Or through RevAddress, which handles the OAuth layer for you:

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

The 8 migration gotchas

These are the issues that catch developers off guard. Knowing them upfront saves hours of debugging.

1. Address1 and Address2 are swapped. Web Tools had a notoriously confusing field naming convention: Address1 was for the apartment or suite number, and Address2 was for the street address — the opposite of what every other address API does. The v3 API corrects this: streetAddress is the primary street line, and secondaryAddress is the unit/suite/apt. If you copy field mappings from old code, your addresses will silently fail or come back incorrect.

2. The 60 req/hr rate limit is real. Web Tools was effectively unlimited for address validation. The v3 API enforces 60 requests per hour per application. At checkout scale — even a modest e-commerce site — this limit hits fast. You can request a higher limit from USPS at emailus.usps.com, but approval is not guaranteed and the process is manual. RevAddress runs pooled OAuth credentials at higher limits; see pricing for details.

3. International country codes changed format. Web Tools accepted country names as strings ("Canada", "United Kingdom"). The v3 international prices API requires ISO 3166-1 alpha-2 country codes (CA, GB). Any international shipping code using country name strings will break silently — you’ll get a 400 or an empty response, not a helpful error message.

4. Label printing requires a separate Payment Authorization token. Getting rates and validating addresses requires a standard OAuth token from developers.usps.com. Printing labels requires an additional Payment Authorization token obtained through USPS Business Customer Gateway (BCG). These are two different credentials, two different flows, and they must both be present in label creation requests. The v3 label API will return a 401 with a cryptic message if the Payment Authorization header is missing.

5. COP claims linking is manual. Certificate of Posting (COP) claims — used to document that a package was tendered to USPS — are not yet automated in the v3 API. If your workflow depended on automated COP claims via Web Tools, that step requires manual intervention until USPS adds it to v3. This affects labels only; address validation, tracking, and rates are unaffected.

6. There is no batch rate API. Web Tools’ RateV4 could accept multiple packages in a single XML request. The v3 POST /prices/v3/total-rates/search is one rate calculation per call. If you were batching rate requests — for example, calculating rates for an entire order manifest — you now need to parallelize individual calls or use a third-party API that batches on your behalf. RevAddress exposes a batch rates endpoint that makes this transparent.

7. Tracking number is now a URL path parameter, not a request body field. In Web Tools, the tracking number went inside the XML body. In v3, it goes in the URL path: GET /tracking/v3/tracking/9400111899223406923658. Any code that constructs a tracking request by inserting a number into an XML template needs to be rewritten to build a URL instead.

8. Dates are ISO 8601. Web Tools used various legacy date formats. The v3 API uses ISO 8601 throughout (2026-03-10T14:30:00Z). Date fields in shipping requests, service standard queries, and responses all follow this format. This is straightforward but will break any code that formats dates in MM/DD/YYYY or similar patterns.

Migration paths by platform

WooCommerce — The fastest path is installing an updated USPS plugin that already calls the v3 API, or using RevAddress as your USPS carrier provider. Full walkthrough: WooCommerce USPS migration guide.

Magento / Adobe Commerce — Adobe released a patch for AC-15210. Apply the official patch if you’re on a supported version. For older Magento versions without an official patch, the RevAddress Magento module is a drop-in replacement. Full walkthrough: Magento AC-15210 fix guide.

Custom PHP — If you built your own integration, you have two choices: rewrite against the v3 API directly (handling OAuth, token refresh, and the field mapping changes above), or drop in the RevAddress PHP client and replace your XML construction code with clean method calls. The PHP client documentation is at /docs/sdks/php.

Python — Install the usps-v3 package from PyPI (pip install usps-v3). It wraps the OAuth flow, handles token refresh, normalizes field names, and exposes all nine v3 API modules as Python methods. Source and docs: PyPI.

pip install usps-v3

from usps_v3 import USPSClient

client = USPSClient(
  client_id="your_client_id",
  client_secret="your_client_secret"
)

result = client.addresses.validate(
  street_address="1600 Pennsylvania Ave NW",
  city="Washington",
  state="DC",
  zip_code="20500"
)

print(result.address.street_address)
# 1600 PENNSYLVANIA AVE NW

Node.js — Install the @revaddress/usps npm package (npm install @revaddress/usps). Same architecture as the Python SDK: OAuth handled internally, snake_case/camelCase normalization, full TypeScript types. Documentation: /docs/sdks/node.

npm install @revaddress/usps

RevAddress API (any language) — If you don’t want to manage USPS OAuth credentials, token refresh, or rate limit pooling, use RevAddress directly. One API key, REST endpoints, no XML, no token management. Flat monthly pricing. See pricing or read the docs.

Timeline of the shutdown

Understanding the timeline helps if you’re explaining this to a client or manager:

• Q3 2024 — USPS officially announces Web Tools deprecation. Migration documentation published.
• 2025 (full year) — v3 REST API is live and available in production. USPS encourages parallel migration. Web Tools continues to function.
• January 25, 2026 — Web Tools officially retired. All endpoints return errors. No grace period extensions.
• March 2026 — Third-party platforms completing enforcement. EasyPost and other intermediaries finalize their own legacy connection removals. Any platform still offering “direct USPS Web Tools” connections is wrapping broken infrastructure.

If your integration broke on or near January 25, 2026, the shutdown is the cause.

The authorization flow, concretely

The biggest conceptual change is OAuth. Here is the exact token acquisition flow for the v3 API:

curl -X POST "https://api.usps.com/oauth2/v3/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET"

{
"access_token": "eyJhbGciOiJSUzI1NiJ9...",
"token_type": "Bearer",
"issued_at": "1741612800000",
"expires_in": "3599",
"status": "approved",
"scope": "addresses tracking prices"
}

curl "https://api.usps.com/addresses/v3/address?streetAddress=1600+Pennsylvania+Ave+NW&city=Washington&state=DC&ZIPCode=20500" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiJ9..."

Tokens expire after one hour. Your integration needs to detect 401 responses and re-authenticate. This token management overhead is one of the main reasons developers use RevAddress — we maintain the OAuth lifecycle so your code just passes an API key.

Verifying your integration is broken

If you’re unsure whether your integration is using Web Tools, search your codebase for these strings:

# In your codebase or server logs, look for:
grep -r "shippingapis.com" .
grep -r "ShippingAPI.dll" .
grep -r "USERID" .
grep -r "AddressValidate" .
grep -r "TrackV2" .
grep -r "RateV4" .

Any match is a live dependency on Web Tools. Those calls are now failing.

What to do right now

1. Identify all Web Tools dependencies using the search patterns above.
2. Choose your migration path: direct v3, SDK, or RevAddress.
3. Handle the Address1/Address2 field swap explicitly — it will silently corrupt addresses otherwise.
4. Build token refresh logic if going direct to v3.
5. Test against the 60 req/hr limit before deploying — confirm your volume is under the default or request an increase.
6. Verify international integrations by testing with ISO country codes.

If you want us to handle steps 2 through 6 for you, sign up for RevAddress — free to start, no credit card required. Or read the full API docs to go direct.

Related guides: USPS v3 address validation quickstart · USPS API pricing in 2026 · Shipping API comparison 2026