USPS's pre-OAuth XML-over-HTTP API. Documented here so integrators searching for USPS Web Tools land on the correct migration path to the modern REST USPS APIs.
Deprecated surface — read before integrating.
USPS Web Tools is deprecated and being replaced by the modern REST USPS APIs. Check the USPS Developer Portal for the current sunset schedule before relying on Web Tools for new work.
Recommended replacement: USPS APIs (REST, OAuth 2.0).
USPS Web Tools is the pre-OAuth USPS API surface. Integrators issue HTTP GET or POST requests with an XML payload encoded into a query parameter (`API=<name>&XML=<payload>`), and authenticate using a UserID passed in the URL. There is no token, no rotation, and no account-scoped authorization beyond the UserID. The contract is XML-only and predates RFC 9457 problem details, so error responses are XML elements rather than structured problem objects.
USPS has been migrating customers off Web Tools onto the modern REST USPS APIs at developer.usps.com. Web Tools still works for many operations at this page's last review, but it is the deprecated surface and integrators should not target it for greenfield work. Existing Web Tools integrations should plan a migration window with parallel running against the REST APIs, because the field shapes, error vocabularies, and account-identifier requirements differ between the two.
This page exists primarily to redirect search traffic. Integrators searching for `USPS Web Tools` should land on a clear explanation of the deprecation and the replacement surface, not on a 404 or on outdated marketing copy. Treat any new Web Tools-only requirement as a sev-3 to investigate, on the assumption that the REST APIs already cover the operation under a different name.
Surface details
- API name
- USPS Web Tools (XML)
- Authentication
- UserID query parameter passed in the URL
- Production base URL
- https://secure.shippingapis.com/ShippingAPI.dll
Frequently asked questions
Can I still create new accounts on USPS Web Tools?
USPS is steering integrators to the modern REST APIs. Treat Web Tools as deprecated and start any new work on developer.usps.com.
Is the UserID-in-URL authentication safe to keep?
It is the only authentication Web Tools supports, but it is materially weaker than the OAuth 2.0 model on the modern USPS APIs. Anything carrying a UserID should be limited to maintenance traffic until migrated.
Will my existing Web Tools fields map one-to-one to the new USPS APIs?
No. Field shapes, error vocabularies, and account-identifier requirements differ. Plan a migration window with parallel running and explicit parity checks rather than a base-URL swap.
Related concepts
Sibling carrier surfaces
Tooling and references
Sources
Last reviewed: 2026-04-25