Skip to content
All Posts
Comparison

Google Address Validation API Pricing in 2026: The Per-Request Curve, the CASS Option, and the 30-Day Caching Rule

·Updated ·10 min read·By RevAddress·Comparison

Google’s Address Validation API is the fastest US address check to stand up. The documentation is good, the key takes minutes, and the free allowance is real. It is also better at postal work than most comparisons give it credit for: it is a CASS Certified™ service, and it returns USPS-standardized output when you ask for it.

What surprises teams is not accuracy. It is the shape of the bill and the shape of the license. The bill is per request and it does not flatten. The license caps how long you may keep what you paid for.

This post covers both, with the current published figures, and then sets them next to a flat monthly plan so the crossover is visible rather than asserted. RevAddress, which publishes this site, is the flat-rate comparison used throughout.

What Google charges

Google Maps Platform prices each SKU separately. The flat $200 monthly credit that used to cover all Maps usage ran until March 1, 2025, and the model that replaced it gives every SKU its own free monthly call allowance. Address Validation has two SKUs.

SKU Free calls/month 0 – 100,000 100,001 – 500,000 500,001 – 1M
Address Validation Pro 5,000 $17.00 / 1,000 $13.60 / 1,000 $10.20 / 1,000
Address Validation Enterprise 1,000 $25.00 / 1,000 $20.00 / 1,000 $15.00 / 1,000

Google Maps Platform pricing, read August 23, 2026. The curve continues past 1M: Pro falls to $5.10 per 1,000 from 1M to 5M and $1.28 per 1,000 above that.

Two details decide which row you are on, and both are easy to get wrong.

The Enterprise SKU is not the “better” tier you opt into. Google’s SKU details page gives the triggers plainly: Pro is billed on a successful request to the Address Validation API, and Enterprise is billed on an Autocomplete (New) session that terminates in a request for address validation. If your form uses Google’s autocomplete and then validates the picked address, you are on the $25 row, not the $17 row.

CASS is not what moves you between them. The CASS flag is not listed as a billing trigger on either SKU. A plain validation call and a CASS-enabled validation call both bill as Pro.

The free allowance is per SKU and per month, and it does not roll over. At 5,000 calls a month you pay nothing. At 5,001 you start paying, and the rate does not soften until 100,000.

The CASS option, and what it does and does not cover

Google’s FAQ, last updated August 11, 2026, answers this directly: the Address Validation API is a CASS Certified™ service. Certification is opt-in per request. Set enableUspsCass to true in the request body, and Google runs the address through CASS processing. The option is available for US and Puerto Rico addresses only, and Google asks for street number, street, city, state and ZIP for it to work well.

So the honest statement about Google is not that it lacks postal grounding. It is that postal grounding is a request flag most integrations never set, on a product whose default behavior is oriented toward putting a correct point on a map.

Three things CASS certification is not, and teams conflate all three:

  • CASS is not NCOA. Certification covers the accuracy of the address coding software. It does not tell you the occupant moved. Move Update processing is a separate USPS program with its own license.
  • CASS is not a mailing statement. Presort discounts require a CASS summary report produced by the processing run, retained and presented with the mailing. A live per-request API call is not the same act as a batch mailing job that outputs one.
  • CASS is not a promise about tomorrow. Certification is periodic. What it certifies is that the software coded correctly against the reference data it held at the time of the run.

If your job is to place an address on a map and catch typos at checkout, none of that matters. If your job ends with a mail piece arriving, all of it does.

The caching terms are the part teams miss

The base Maps Platform Terms of Service are restrictive by default. Section 3.2.3(b) reads: “Customer will not cache Google Maps Content except as expressly permitted under the Maps Service Specific Terms.” Section 3.2.3(a) separately prohibits pre-fetching, indexing, storing, resharing or rehosting Maps Content outside the services.

Address Validation is one of the products that gets an express permission, and it is worth reading before you design a schema around it. The Service Specific Terms grant a caching window with three rows:

What you may cache How long For what purpose
formattedAddress, postalAddress, addressComponent: componentName, USPS Data standardizedAddress 30 consecutive calendar days Downstream transactions
addressComponent: confirmationLevel, inferred, spellCorrected, replaced, unexpected 30 consecutive calendar days Correction requests
Latitude and longitude values 30 consecutive calendar days Any

Google Maps Platform Service Specific Terms, Table 1.3.2, read August 23, 2026.

At the end of 30 days you must delete the cached content, or replace it with data the end user confirmed or corrected. That is a real constraint on a customer address table, which is a record you expect to keep for years. It is not a constraint on a geocode you cached to draw a map.

One more clause in the same section deserves its own paragraph, because it catches engineering teams during load testing. Section 1.2 prohibits requests with artificially-created addresses for US and Puerto Rico. Google states what happens if you send one: it will stop validating your addresses using USPS services, and it will report your name and address, the relevant input address, and aggregated usage data to the Postal Service. Seed a test suite with invented street numbers against the US endpoint and you are not risking a warning, you are risking the account.

Section 1.1 also notes that using the Address Validation API means agreeing that Google may share your name and address with the Postal Service.

Where the per-request curve lands next to a flat plan

Google’s rate is the same whether CASS is on or off, so the comparison below is like for like on output. The RevAddress column is the plan whose published monthly request cap covers the volume, taken from the pricing page.

US lookups/month Google (Pro SKU) RevAddress plan Cheaper by
1,000 $0 (free allowance) Free, $0 tie
5,000 $0 (free allowance) Starter, $29 Google, $29
10,000 $85 Growth, $79 RevAddress, $6
25,000 $340 Growth, $79 RevAddress, $261
50,000 $765 Pro, $199 RevAddress, $566
100,000 $1,615 Pro, $199 RevAddress, $1,416

Google is cheaper below roughly 9,600 lookups a month, and its 5,000-call free allowance is five times the 1,000 requests on the free RevAddress key. For a small storefront validating a few thousand checkouts, Google costs nothing and this post is not for you.

Above that line two things change. The gap opens, because $17 per 1,000 keeps applying all the way to 100,000. And the comparison stops being one number against another, because of where each product gets its USPS data.

Which license the USPS data runs on

This is the part a price table cannot carry, and it is the real difference between the two products.

Google holds its own CASS certification and its own USPS relationship. You pay Google, Google handles the Postal Service, and you never see a license agreement.

RevAddress does not work that way, and the pricing above only makes sense once you know why. There are two routes, and the second is the reason the flat plan is not the whole bill.

Census-based standardization, at no cost. Standardization, geocoding and address extract run against the US Census Bureau’s public address inventory. No USPS license, no per-lookup fee, 1,000 requests a month on the free key. It puts an address into correct postal form and returns street-level coordinates. It does not return DPV, ZIP+4, or any USPS deliverability flag, and the response says so in classification and userMessage rather than leaving you to infer it. RevAddress is not a CASS-certified vendor and does not perform NCOA processing.

The full USPS suite on your own license. You sign the USPS Addresses API agreement, you pay the USPS fee curve directly, and you point RevAddress at your credentials. From there the whole postal stack runs on your license and on this infrastructure: DPV verification with ZIP+4, CMRA, vacant and business flags, plus rates, service standards and tracking. Label creation and voids come in at the Pro tier. RevAddress manages the OAuth lifecycle, the rate-limit budget, the caching policy and the retries, so the parts that break at 3am are handled. The Postal Service relationship stays yours, which is what gives you your own reporting and your own compliance posture.

So the total, for a team that wants USPS-verified output, is the plan fee plus the USPS fee on their own license. USPS bills on monthly consumption at a single tier, rounding partial thousands up:

US lookups/month Google (CASS on) RevAddress plan Your USPS fee Total
10,000 $85 $79 $45.00 $124.00
25,000 $340 $79 $106.25 $185.25
50,000 $765 $199 $212.50 $411.50
100,000 $1,615 $199 $400.00 $599.00

USPS figures from the Addresses API Tech Sheet, updated 2026-08-13. The USPS pricing breakdown walks the whole curve and the license process.

At 10,000 a month Google is still the cheaper single bill and the simpler one. At 25,000 the combined route costs about half. At 100,000 it costs about a third. The crossover is not where the first table alone suggests, and quoting the first table without this one would be the easier argument to make and the wrong one.

Moving a call across

Both are JSON over HTTPS. The field names differ and the key moves from a query parameter to a header.

Google, then RevAddress
curl -X POST \
"https://addressvalidation.googleapis.com/v1:validateAddress?key=$GOOGLE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "address": {
    "regionCode": "US",
    "addressLines": ["1600 Pennsylvania Ave NW"],
    "locality": "Washington",
    "administrativeArea": "DC"
  },
  "enableUspsCass": true
}'

Four mechanical notes for the migration:

  1. The path is /api/address/validate. GET with query parameters works too, which is useful for a smoke test from a browser.
  2. The payload is flat. Google nests under address with addressLines as an array. RevAddress takes top-level streetAddress, city, state, ZIPCode, and normalizes common aliases, so street_address, address1, line1, zip and zip_code all resolve rather than returning a 400.
  3. Read the classification, not a boolean. Google’s verdict object is replaced by classification and nextAction, which distinguish a Census-standardized answer from a USPS-verified one. The distinction is the whole point of reading it.
  4. Batch is a different endpoint. POST /api/batch/validate takes up to 50 addresses per call and settles each independently, so one malformed record returns its own error instead of failing the batch. Details in the batch validation guide.

On repeat addresses, be precise about what caching buys. RevAddress holds Census-standardized results for 24 hours, so re-running last week’s list does not re-derive them and does not spend a USPS transaction. It still spends a request against your monthly cap, and it does not apply to USPS-verified answers at all: the USPS license requires every verified response to round-trip rather than be served from a cache. Cached lookups are cheaper, not free of the count.

Which one to pick

  • Under 5,000 US lookups a month, mapping or checkout typo-catching: Google. It is free at that volume and the free allowance is generous.
  • 5,000 to 10,000 a month, single bill preferred: Google, unless the 30-day caching window conflicts with how long you keep customer addresses.
  • Above 25,000 a month, USPS-verified output required: a flat plan plus your own USPS license, which is roughly half the cost and puts the Postal Service relationship in your name.
  • Standardizing and geocoding a list with no deliverability check: Census-based validation at no cost. No license, no fee, no caching clock.
  • International addresses: Google. RevAddress is US-only by design.
  • A one-time file, not an integration: neither. List Clean takes a CSV and returns it standardized, deduplicated and geocoded from $19.

Sources

Vendor pricing moves. Check the linked pages before you budget against any figure here.

Start here

Questions

How much does Google's Address Validation API cost?
The Address Validation Pro SKU includes 5,000 free calls a month, then bills $17.00 per 1,000 calls up to 100,000, $13.60 per 1,000 from 100,001 to 500,000, and $10.20 per 1,000 from 500,001 to 1,000,000. Those figures are published on the Google Maps Platform pricing page and were current on August 23, 2026.
Is Google's Address Validation API CASS Certified?
Yes. Google's own FAQ, last updated August 11, 2026, states that the Address Validation API is a CASS Certified service. CASS processing is opt-in. Set enableUspsCass to true in the request body, and it applies to US and Puerto Rico addresses only.
Does enabling CASS on Google cost extra?
Not as a separate SKU. Google's SKU details page says the Pro SKU is triggered by any successful Address Validation request, and the Enterprise SKU is triggered by an Autocomplete session that terminates in a validation request. The CASS flag is not listed as a billing trigger.
Can I store Google address validation results in my database?
Only within the published window. The Maps Platform Service Specific Terms permit temporarily caching the formatted address, postal address, address components and USPS standardized address for 30 consecutive calendar days, after which you must delete the cached content or replace it with data the end user confirmed. Latitude and longitude may be cached for 30 days for any purpose.
Can I test Google's US address validation with made-up addresses?
No. The Service Specific Terms prohibit requests with artificially-created addresses for US and Puerto Rico. Google states that if you submit one, it will stop validating your addresses using USPS services and will report your name and address, the input address, and aggregated usage data to the Postal Service.