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.
[null,null,["上次更新時間：2025-08-31 (世界標準時間)。"],[[["\u003cp\u003eThis document outlines address validation techniques specific to the United States, focusing on leveraging USPS data for enhanced accuracy.\u003c/p\u003e\n"],["\u003cp\u003eThe USPS Delivery Point Verification (DPV) codes (N, D, S, Y) provide insights into address deliverability, allowing systems to identify potential issues and prompt users for corrections.\u003c/p\u003e\n"],["\u003cp\u003eWhile the \u003ccode\u003euspsData\u003c/code\u003e object offers valuable information for US addresses, it's crucial to incorporate other validation response elements for comprehensive verification due to its potential for incomplete population.\u003c/p\u003e\n"],["\u003cp\u003eSecurity measures are in place to detect artificially created addresses, triggering an error message within the \u003ccode\u003euspsData\u003c/code\u003e if such an address is identified, while other response properties remain unaffected.\u003c/p\u003e\n"]]],["The document details how to use USPS data for US address validation via an API. The `uspsData` object, specifically the `dpvConfirmation` field, indicates address deliverability. `Y` means the address is fully deliverable; `S` means the sub-premise is unconfirmed; `D` indicates a missing sub-premise; `N` or empty implies the primary address is invalid. Artificially created addresses trigger an error message in `uspsData`, and their detection does not affect other response properties. The provided examples can be used as a reference for what kind of values and scenarios could be encountered when using this API.\n"],null,["\u003cbr /\u003e\n\nThis document covers address validation specific to the United States:\n\n- [Using USPS data in your workflow](#using-usps-data)\n- [USPS Delivery Point Verification](#usps-delivery) fields (dpv)\n- [Security messages](#security-messages)\n\nUSPS data in your workflow\n\nWhen validating addresses in the United States, the Address Validation API service\ncan also populate the [uspsData](https://developers.google.com/maps/documentation/address-validation/reference/rest/v1/TopLevel/validateAddress#uspsdata) portion of the return.\n| **Key Point:** If your system primarily or exclusively handles US addresses, you may elect to use this response object as a first point of reference in your checking logic. However, it's important to know that the `uspsData` object is not guaranteed to be fully populated for every address validated by the service.\n\nBecause this object is not always populated, you shouldn't rely on this\nproperty as the sole means to validate addresses, but instead incorporate the\nverdict and address components into your system as well.\n\nUSPS Delivery Point Verification (DPV)\n\nAs part of the `uspsData` response, the `dpvConfirmation` field returns a single\ncharacter to let you know if the USPS can deliver to the provided address.\n\nYou can use this field to determine the following:\n\n- address validity.\n- if a sub-premise number is missing from the address.\n- if the sub-premise number does not exist in the USPS data system.\n\nThe service either returns one of four `dpvConfirmation` values or it does not\nreturn a `dpvConfirmation` value at all. The table below shows the possible\nbehavior your logic could use for each of the 5 possible outcomes. For more\ndetails on this logic, see\n[Example workflows](/maps/documentation/address-validation/build-validation-logic#example-workflows) in\n**Build your validation logic.**\n\n| **Value** | **Behavior** | **Description** |\n|------------|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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 likely cannot deliver there. |\n| D | Add a subpremises | The address was DPV confirmed for the primary number only, and the secondary number information was missing. \u003cbr /\u003e This means that the premise number entered exists on the entered street, but to reach a fully verified/deliverable address, a valid sub-premise number also needs to be provided. In other words, the sub-premise was missing from the input. |\n| 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. |\n| 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. |\n\nThe rest of this section discusses real world scenarios that use the DPV codes.\n\nDPV N example - fix the address\n\nThis example uses a non-existent street number on an otherwise valid address.\n\n- **Address entered**: 12 Amphitheatre Parkway, Mountain View, CA, 94043\n- **Region**: USA\n- The `dpvConfirmation` field returns: `N`\n\nThis is an **extremely strong signal** that this premise number does not exist\non this route. As with other problematic addresses, your system should prompt\nthe user for corrections.\n\nDPV D example - add a subpremises\n\nThis example uses the Google office in New York, but does not contain a\nsub-premise which is a required part of the address. You can see this by using\nthe address in the [demo](https://developers.google.com/maps/documentation/address-validation/demo) without sub-premise information.\n\n- **Address entered**: 111 8th Avenue, New York, NY, 10011\n- **Region**: USA\n- The `dpvConfirmation` field returns: `D`\n\nThis confirms that the sub-premise was missing from the input. To get to a DPV\nof Y, a valid sub-premise must be included as part of the input. For example,\nyou could include a valid sub-premise of *FL 4* (4th Floor) to obtain a\n`dpvConfirmation` value of Y.\n\nDPV S example - confirm the address\n\nThis example uses a sub-premise number that does not exist within the building:\n\n- **Address entered**: 1600 Amphitheatre Parkway, Suite 101, Mountain View, CA, 94043\n- **Region**: USA\n- The `dpvConfirmation` field returns: `S`\n\nThis indicates that, while 1600 Amphitheatre Parkway is a valid address, the\nsub-premise *Suite 101* is not a valid part of the address. You might consider\nconfirming this information with the user and provide an opportunity for a\ncorrection.\n\nDPV Y example - accept the address\n\nThis example uses the Googleplex address in Mountain View, CA as a\nknown valid address.\n\n- **Address entered**: 1600 Amphitheatre Parkway, Mountain View, CA, 94043\n- **Region**: USA\n- The `dpvConfirmation` field returns: `Y`\n\nThe address is fully deliverable by USPS. This gives you a very high degree of\nconfidence that the API returned an address of good quality, and you can likely\nuse it as provided. As always, consider your\n[risk level](https://developers.google.com/maps/documentation/address-validation/build-validation-logic#implementation_guidance) when deciding whether or not to prompt\nyour customer for confirmation.\n\n**Note**: The DPV does not indicate if the Address Validation API has made any\nchanges to the input, such as a spell correction.\n\nSecurity messages for US addresses\n\nThis section covers the security flags provided in the USPS data for\nartificially created addresses. This security measure is designed to prevent the\nartificial creation of an address list by detecting when a submitted address\nappears to have been constructed artificially and not obtained legitimately.\nThis should be a very rare occurrence.\n\nWhen the USPS identifies an artificially created address, the `errorMessage`\nfield of the [uspsData](https://developers.google.com/maps/documentation/address-validation/reference/rest/v1/TopLevel/validateAddress#uspsdata) property of the response contains an\nerror message describing the issue. For example: \n\n AMS API processing was terminated due to the detection of what is determined to\n be an artificially created address. No address beyond this point has been\n validated and/or processed. If you believe this address was identified in error,\n please contact your Vendor.\n\n| **Note:** When the `uspsData` indicates an artificial address, the response for other properties in the Address Validation API response remain unaffected."]]
