USPS address validation API: current endpoints and alternatives

Use the current USPS Addresses API

The official USPS Addresses API is a separate service operated by USPS. Its current REST interface uses OAuth, not a legacy Web Tools USERID. Check the developer portal and your account's Addresses API license before implementing against production.

Official USPS address endpoints

GET https://apis.usps.com/addresses/v3/address
Testing: https://apis-tem.usps.com/addresses/v3/address
Authentication: OAuth bearer token
Inputs: streetAddress, optional secondaryAddress, and city/state or ZIPCode

Keep ZIPCode and ZIPPlus4 as strings. Preserve apartment information in secondaryAddress, and check errors rather than treating an empty match as a standardized address. Test-environment access does not prove production entitlement.

Old Web Tools examples need migration

USPS retired the Web Tools platform on January 25, 2026. An old XML example targeting ShippingAPI.dll is not a current integration plan. Use USPS's migration documentation to map the old request and response fields to the new API.

Migration includes credentials, account access, field mapping and errors, not only changing a hostname. Test both corrected-address cases and failures in the permitted environment before switching a checkout. Do not assume a quota, fee or use permission from an old tutorial still applies.

Decide what evidence you need

Three different outcomes often called address validation
Outcome	What it supports	What it does not prove
Normalized address	Consistent formatting and structured components	A correct apartment or confirmed delivery point
Geocoding match	Locating an address or building on a map	Postal or carrier deliverability
Postal verification evidence	A decision based on the documented postal checks and coverage	The identity of an occupant or a successful future delivery

Direct USPS access or another provider?

Direct USPS access is worth evaluating for a domestic postal-standardization requirement when its current account terms fit the workload. A specialist or shipping platform can offer a different integration boundary. Neither approach should be selected by a headline confidence percentage.

Choose the integration around your workflow
Option	When to examine it	Important boundary
Google Address Validation	A confirm/correct flow within Google Maps Platform	Country coverage, verdict fields and optional US/PR CASS settings
Smarty	US postal candidates and secondary-address analysis	US and International products are separate
Loqate	International address cleansing and batch processing	Interpret country-specific quality codes and batch records
EasyPost / Shippo	Checks before a shipping workflow or label creation	Validation access and success are separate from creating a shipping object
Geoapify	Location matching when postal delivery evidence is not required	Geocoding confidence is not USPS DPV

Compare endpoints, billing models and every provider pair.

Keep the decision separate from the provider

Keep the original input, proposed correction, changed fields and supporting evidence separate in your application's data model. Route unsupported countries and missing evidence to review rather than silently marking them invalid. Ask the customer to confirm material changes before changing a shipping destination.

Use approved fixtures or consented records for evaluation. Do not send private address lists to a provider merely to try a demo, and do not generate arbitrary postal addresses. Keep addresses and credentials out of analytics, public URLs and application logs.

Our All Them APIs request contract describes the intended normalized interface and lets you request access. It is not the official USPS service, and this additional category requires enablement before any API execution.

Sources and review dates

Official documentation reviewed October 28, 2026. This is an integration guide, not a USPS affiliation, postal certification or a measured provider ranking.

Corrections: email faizank@docsalot.dev with an official source.