This document covers address validation specific to the United States:
USPS data in your workflow
When validating addresses in the United States, the Address Validation API service can also populate the uspsData portion of the return.
Because this object is not always populated, you shouldn't rely on this property as the sole means to validate addresses, but instead incorporate the verdict and address components into your system as well.
USPS Delivery Point Verification (DPV)
As part of the uspsData
response, the dpvConfirmation
field returns a single
character to let you know if the USPS can deliver to the provided address.
You can use this field to determine the following:
- address validity.
- if a sub-premise number is missing from the address.
- if the sub-premise number does not exist in the USPS data system.
The service either returns one of four dpvConfirmation
values or it does not
return a dpvConfirmation
value at all. The table below shows the recommended
behavior your logic should use for each of the 5 possible outcomes. For more
details on this logic, see
Workflow overview in Use the validation response.
Value |
Behavior |
Description |
---|---|---|
N or empty |
Fix the address |
The address was not DPV confirmed. This means the USPS does not recognize the entered premise number existing on the entered street (route), and cannot deliver there. |
D |
Fix the address |
The address was DPV confirmed for the primary number only, and the
secondary number information was missing. |
S |
Confirm the address |
The address was DPV confirmed for the primary number only, and the secondary number information was present but not confirmed. This means that the premise number entered exists on the entered route, but the sub-premise provided does not exist within that building, according to USPS. |
Y |
Accept the address |
The address was DPV confirmed for primary and any secondary numbers. This means the address is fully deliverable by USPS, including the sub-premise number, if applicable. |
The rest of this section discusses real world scenarios that use the DPV codes.
DPV N example - fix the address
This example uses non-existent street number on an otherwise valid address.
- Address entered: 12 Amphitheatre Parkway, Mountain View, CA, 94043
- Region: USA
- The
dpvConfirmation
field returns:N
This is an extremely strong signal that this premise number does not exist on this route. As with other problematic addresses, your system should prompt the user for corrections.
DPV D example - fix the address
This example uses the Google office in New York, but does not contain a sub-premise which is a required part of the address. You can see this by using the address in the demo without sub-premise information.
- Address entered: 111 8th Avenue, New York, NY, 10011
- Region: USA
- The
dpvConfirmation
field returns:D
This confirms that the sub-premise was missing from the input. To get to a DPV
of Y, a valid sub-premise must be included as part of the input. For example,
you could include a valid sub-premise of FL 4 (4th Floor) to obtain a
dpvConfirmation
value of Y.
DPV S example - confirm the address
This example uses a sub-premise number that does not exist within the building:
- Address entered: 1600 Amphitheatre Parkway, Suite 101, Mountain View, CA, 94043
- Region: USA
- The
dpvConfirmation
field returns:S
This indicates that, while 1600 Amphitheatre Parkway exists as an address that can accept mail, the sub-premise Ste 101 is not a valid part of the address. Your system should confirm this information with the user and provide an opportunity for a correction.
DPV Y example - accept the address
This example uses the Googleplex address in Mountain View, CA as a known quality address.
- Address entered: 1600 Amphitheatre Parkway, Mountain View, CA, 94043
- Region: USA
- The
dpvConfirmation
field returns:Y
The address is fully deliverable by USPS. This gives you a very high degree of confidence that the API returned an address of good quality, and you can use it as provided.
Note: The DPV does not indicate if the Address Validation API has made any changes to the input, such as a spell correction.
Security messages for US addresses
This section covers the security flags provided in the USPS data for artificially created addresses. This security measure is designed to prevent the artificial creation of an address list by detecting when a submitted address appears to have been constructed artificially and not obtained legitimately. This should be a very rare occurrence.
When the USPS identifies an artificially created address, the errorMessage
field of the uspsData property of the response contains an
error message describing the issue. For example:
AMS API processing was terminated due to the detection of what is determined to
be an artificially created address. No address beyond this point has been
validated and/or processed. If you believe this address was identified in error,
please contact your Vendor.