{"standardizedAddress":{"firstAddressLine":"155 VIA CONDADO WAY","cityStateZipAddressLine":"PALM BEACH GARDENS","city":"PALM BEACH GARDENS","state":"FL","zipCode":"33418"},"carrierRoute":"H018","postOfficeCity":"PALM BEACH GARDENS","postOfficeState":"FL"}
[null,null,["上次更新時間:2025-08-17 (世界標準時間)。"],[],[],null,["\u003cbr /\u003e\n\n| This product or feature is in Preview (pre-GA). Pre-GA products and features might have limited support, and changes to pre-GA products and features might not be compatible with other pre-GA versions. Pre-GA Offerings are covered by the [Google\n| Maps Platform Service Specific Terms](https://cloud.google.com/maps-platform/terms/maps-service-terms). For more information, see the [launch stage\n| descriptions](/maps/launch-stages).\n\n\u003cbr /\u003e\n\nThis document describes a number of real-world scenarios where the\nAddress Validation API provides response signals that warrant an *accept*\nbehavior from your system. See\n[Workflow overview](/maps/documentation/javascript/address-validation/use-validation-response#workflow-overview)\nin **Use the validation response** for context.\n| **Note:** the examples here are illustrative, but not exhaustive.\n\nCommon example: accept\n\nThis scenario illustrates an address in which your system would accept an\naddress entered by a customer.\n\n| Address entered | Region |\n|--------------------------------------------|--------|\n| 76 Buckingham Palace Road, London SW1W 9TQ | UK |\n\nVerdict for an acceptable address\n\nThe example below highlights the important signals. \n\n {\n \"inputGranularity\": \"PREMISE\",\n \"validationGranularity\": \"PREMISE\",\n \"geocodeGranularity\": \"PREMISE\",\n \"addressComplete\": true\n }\n\nIn addition to this, the [`verdict`](/maps/documentation/javascript/reference/address-validation#Verdict)\nindicates the following:\n\n- `hasUnconfirmedComponents` remains `false`\n- `hasInferredComponents` remains `false`\n- `hasReplacedComponents` remains `false`\n\nWhen combined together, these signals indicate a high-quality address.\n| **Action:** Accept.\n\nEdge case examples: accept\n\nThe following examples cover situations in which the\n[`verdict`](/maps/documentation/javascript/reference/address-validation#Verdict)\nindicates address quality issues that warrant further investigation. These\nexamples also illustrate how your logic can travel from the verdict to the\naddress components to obtain a more complete picture in order to enhance your\nsystem logic.\n| **Note:** these examples are not exhaustive, but representative.\n\nNon-US unconfirmed street number\n\nThis example illustrates entry of an Italian address with all address components\npresent, along with no inferred or replaced components. However, the\n[`validationGranularity`](/maps/documentation/javascript/reference/address-validation#Verdict.validationGranularity)\nis `ROUTE`.\n\n| Address entered | Region |\n|-------------------------------------------------------|--------|\n| Via Fonte Grugnale, 14 unit 2, 66054 Vasto CH, Italia | IT |\n\nVerdict for an unconfirmed street number \n\n {\n \"inputGranularity\": \"SUB_PREMISE\",\n \"validationGranularity\": \"ROUTE\",\n \"geocodeGranularity\": \"ROUTE\",\n \"addressComplete\": true,\n \"hasUnconfirmedComponents\": true\n }\n\nFurther investigation of the address components reveals that the\n[confirmation level](/maps/documentation/javascript/reference/address-validation#ConfirmationLevel)\nfor the street number is `UNCONFIRMED_BUT_PLAUSIBLE`. \n\n {\n \"text\": \"14\",\n \"componentType\": \"street_number\",\n \"confirmationLevel\": \"UNCONFIRMED_BUT_PLAUSIBLE\"\n }\n\n| **Action:** This address can be accepted without further prompting. However, for a higher confidence level, you can prompt the customer to confirm the address. See [Implementation guidance](/maps/documentation/javascript/address-validation/build-validation-logic#implementation_guidance) in **Build your validation logic** for more details.\n\nUS unconfirmed street number\n\nThis example illustrates entry of a US address with all address components\npresent, with no inferred or replaced components. However, the\n[`validationGranularity`](/maps/documentation/javascript/reference/address-validation#Verdict.validationGranularity)\nis `PREMISE_PROXIMITY`.\n\n| Address entered | Region |\n|------------------------------------|--------|\n| 975 Carson Dr, Sunnyvale, CA 94086 | US |\n\nUSPS data for an unconfirmed street number \n\n {\n \"firstAddressLine\": \"975 CARSON DR\",\n \"cityStateZipAddressLine\": \"SUNNYVALE CA 94086\",\n \"city\": \"SUNNYVALE\",\n \"state\": \"CA\",\n \"zipCode\": \"94086\"\n \"dpvConfirmation\": \"N\",\n \"dpvFootnote\": \"AAM3\",\n \"carrierRoute\": \"C031\",\n \"carrierRouteIndicator\": \"D\",\n \"postOfficeCity\": \"SUNNYVALE\",\n \"postOfficeState\": \"CA\",\n \"fipsCountyCode\": \"085\",\n \"county\": \"SANTA CLARA\",\n }\n\n| **Action:** Fix. This example is similar to the previous one, and the address can be accepted as entered. However, the additional `dpvConfirmation` code of `N` provides a strong signal to confirm the address with the customer or prompt them to fix it. The behavior you choose for this case ultimately depends on your required confidence level. See [Implementation guidance](/maps/documentation/javascript/address-validation/build-validation-logic#implementation_guidance) in **Build your validation logic** for more details.\n\nIncomplete USPS data for a confirmed address\n\nThis example illustrates entry of a US address with all address components\nconfirmed, with no inferred or replaced components, and a\n[`validationGranularity`](/maps/documentation/javascript/reference/address-validation#Verdict.validationGranularity)\nof `PREMISE`. However, the [`uspsData`](/maps/documentation/javascript/reference/address-validation#USPSData)\nis not fully populated, and does not contain a `dpvConfirmation` value.\n\n| Address entered | Region |\n|--------------------------------------------------------|--------|\n| 155 Via Condado Way, Palm Beach Gardens, FL 33418-1703 | US |\n\nVerdict for a confirmed address with incomplete USPS data \n\n {\n \"inputGranularity\": \"PREMISE\",\n \"validationGranularity\": \"PREMISE\",\n \"geocodeGranularity\": \"PREMISE\",\n \"addressComplete\": true,\n }\n\nUSPS data for a confirmed address with incomplete USPS data \n\n {\n \"standardizedAddress\": {\n \"firstAddressLine\": \"155 VIA CONDADO WAY\",\n \"cityStateZipAddressLine\": \"PALM BEACH GARDENS\",\n \"city\": \"PALM BEACH GARDENS\",\n \"state\": \"FL\",\n \"zipCode\": \"33418\"\n },\n \"carrierRoute\": \"H018\",\n \"postOfficeCity\": \"PALM BEACH GARDENS\",\n \"postOfficeState\": \"FL\"\n }\n\n| **Action:** Accept. Even though the address is not DPV confirmed by the USPS, the `validationGranularity` of `PREMISE` gives a strong signal that this is a valid address. However, for a higher confidence level, you can prompt the customer to confirm the address. See [Implementation guidance](/maps/documentation/javascript/address-validation/build-validation-logic#implementation_guidance) in **Build your validation logic** for more details.\n| **Note:** The service receives updated USPS data periodically, so this example may no longer return incomplete USPS data. This example is meant to be illustrative rather than an accurate portrayal of the API response for this address."]]