Skip to Content
Odoo 19.0 · Address Validation · Contacts · 3 Modules

Contact Address Validation Google

Verify every contact address is real and deliverable — one click sends it to the Google Address Validation API, returns a standardized address with component-level confirmation, and writes the geocoded coordinates back to the record. Built on a provider-agnostic framework, so the workflow never changes if you later switch to PostGrid or Smarty.

Contact Shop
Address Validation API USPS CASS™ Provider Framework Contacts Integration

Product Overview

Contact Validation Google brings the Google Address Validation API to the Odoo Contact form. It checks whether an entered address refers to a real, deliverable place, standardizes it for mailing, and geocodes it — directly from the Contact form, without leaving Odoo.

Unlike a single-purpose connector, this product is built on a provider-agnostic address validation framework. The button, the review dialog, the stored verdict, and the search filters are shared framework components; Google plugs in as a provider adapter. If your requirements ever change — different regions, different pricing, different compliance needs — you can switch to the PostGrid or Smarty adapter from Settings, and your users' workflow stays exactly the same.

Clicking Verify Address sends the contact's address to the API via a secure server-side request — the API key never reaches the browser. A dialog opens with Google's verdict translated into a clear severity (Valid, Needs Review, or Invalid), a side-by-side comparison of the entered and standardized addresses, and a component breakdown showing the confirmation level of every address part, including inferred, replaced, and spell-corrected components. The user chooses to apply the standardized address, keep the current address while storing only the verdict, or discard without writing anything.

For US and Puerto Rico addresses, USPS CASS™ (Coding Accuracy Support System) processing is enabled automatically, providing the Delivery Point Validation (DPV) confirmation code. In line with the Google Maps Platform terms, Google's standardized address is shown for review only — what gets saved on the contact is always the address the user explicitly confirms.

Who It's For

Logistics & Delivery Teams Verify delivery addresses before dispatch. Catch incomplete or unrecognized addresses at data-entry time rather than at the warehouse door — before a shipment fails or a driver navigates to the wrong location.
Marketing & Direct Mail Teams Standardize and validate mailing lists to reduce returned mail, improve postage efficiency, and meet USPS deliverability standards for US campaigns — before printing labels, not after bounce reports.
Sales & CRM Teams Ensure customer and prospect addresses are geocoded and standardized so map views, territory assignments, and proximity filters work on clean, verified data from the moment a contact is created.
Operations & Data Quality Teams Use the built-in search filters to audit the contact database — find unverified, problematic, or invalid addresses in bulk and prioritize clean-up without writing a custom domain or running an export.

The Problem It Solves

No Feedback at Entry Time

Odoo's address fields are free-text. Typos, incomplete streets, and non-existent postcodes are saved without warning and propagate to every downstream process that reads the contact's address — from shipping labels to invoice footers.

Locked Into One Validation Vendor

Most address validation connectors hardwire one provider into fields, views, and code. Changing vendors later means migrating data and retraining users. Here the provider is a plug-in choice — the workflow, fields, and filters are shared.

Inconsistent Address Formats

Addresses entered by different users follow different conventions. Standardizing them for mailing, reporting, or API submission is a manual and error-prone task without a validation step that enforces a canonical format.

No Visibility Into Data Quality

Without a stored verification status, there is no way to filter or report on which contacts have verified addresses and which need attention — until something breaks downstream and the damage is already done.

What's Inside

Three modules — a shared validation framework, the Google provider adapter, and the Contacts application module — bringing verified, standardized, geocoded addresses to every Odoo Contact record.

Module 01 · Foundation

Base Address Validation

The provider-agnostic framework. It defines the provider registry, the reusable verification mixin (status fields, automatic reset, verify and apply actions), and the generic Verify Address widget and review dialog shared by every provider. Provider statuses are stored verbatim, while a shared severity (success / warning / danger) drives badges, filters, and the Apply guard.

Provider registry Validation mixin Generic OWL widget + dialog Severity model Depends on: base_setup, web

Why It Exists

Centralising the workflow in one framework means the button, dialog, stored fields, and filters are identical no matter which provider is active — and switching providers is a Settings change, not a data migration.

Module 02 · Provider Adapter

Address Validation: Google

Registers Google as a provider. All API logic lives in a server-side service model — request building, USPS CASS™ activation for US/PR, response parsing, and per-status error mapping. Google's verdict is translated into three clear statuses — Valid, Needs Review, or Invalid — following Google's own accept / confirm / fix guidance.

Address Validation REST API Server-side requests USPS CASS™ / DPV Depends on: base_address_validation, base_google_map

Terms-of-Service Compliant

Per Google Maps Platform caching terms, Google's standardized address is displayed for review only — never stored on the record or in the chatter. The address that gets saved is always the one the user explicitly confirms in the dialog.

API Key Setup

Enable the Address Validation API in your Google Cloud project. Use API restrictions with an IP allowlist or no application restriction — HTTP-referrer-restricted keys are rejected server-side by this API. On Odoo.sh (no static IP), rely on API restrictions plus usage quotas.

Module 03 · Application · Contacts

Contacts Address Validation

Applies the framework to Contacts. The Contact form gains the Verify Address button and the severity-colored status badge; the Contacts list gains verification filters. Every verification is logged in the chatter — including old → new coordinates when they change — and editing any address field resets the status automatically.

Verify button on Contact form Severity search filters Chatter audit trail Depends on: base_address_validation, base_geolocalize, contacts

How It Works

The entire flow — from button click to stored verdict — stays inside Odoo. The API key never leaves the server.

  1. Open a Contact and enter an address. The Verify Address button appears below the address block on the Contact form as soon as the modules are installed and Google is selected as the provider in Settings.
  2. Click Verify Address. Any pending form edits are saved automatically before the request is sent, ensuring the stored verdict always matches the address that was actually verified.
  3. Odoo sends a server-side API request. The address is submitted to the Google Address Validation API with the contact's country as the region code. USPS CASS™ processing is enabled automatically for US and Puerto Rico addresses.
  4. Review the verification dialog. The dialog opens with a severity banner explaining Google's verdict in plain language, a side-by-side comparison of entered vs. standardized address, a component table with confirmation levels, anything missing from the entered address, and — for US/PR — the DPV confirmation code.
  5. Choose an action. Apply Standardized Address — writes the confirmed address and geocoordinates to the contact and stores the verdict. Keep Current Address — stores only the verdict without changing the address. Discard — closes the dialog without writing anything.
  6. The status badge reflects the stored verdict. Valid, Needs Review, or Invalid is shown next to the button, and the verification is logged in the chatter. If any address field is later edited, the status resets to Not Verified automatically — stale verdicts never linger after an address change.

Key Features

Real-time address verification with component-level confirmation, USPS CASS™ processing, and a stored, searchable audit trail — on a framework that lets you change providers without changing the workflow.

Verification & Dialog

  • Verify Address button — One-click verification from the Contact form; pending edits are saved automatically before the request.
  • Severity banner — Google's verdict explained in plain language, color coded green / yellow / red so users know whether to accept, double-check, or fix.
  • Side-by-side address comparison — Entered address vs. Google's standardized address, shown together so the user sees exactly what would change.
  • Component-level confirmation — Every address component listed with its confirmation level, plus inferred, replaced, and spell-corrected flags, and a clear callout of components missing from the entered address.
  • Three dialog actions — Apply Standardized Address, Keep Current Address (verdict only), or Discard (no write).

Address Application & Geocoding

  • Apply the confirmed address in one write — Street, street2, city, state, zip, and country written in a single operation; state and country records resolved server-side by code.
  • Geocoordinates from the validation response — Latitude and longitude written to the contact in the same call, with the old coordinates logged in the chatter — no separate geocoding step needed.
  • USPS CASS™ for US & PR — DPV confirmation code shown in the dialog and logged in the chatter. Google's standardized address is displayed only, never stored, per Google Maps Platform terms.

Framework & Data Quality

  • Provider-agnostic framework — Switch to PostGrid or Smarty from Settings later; fields, filters, and the user workflow stay identical.
  • Stored verification status — Valid / Needs Review / Invalid stored on the contact together with the severity, provider, DPV code, and verification date.
  • Automatic status reset — Editing street, street2, city, zip, state, or country resets the status to Not Verified — stale verdicts never persist.
  • Search filters by outcome — Built-in Contacts filters for verified, needs-review, failed, and not-verified addresses — no custom domain required.
  • Secure credentials — The API key is stored in Odoo system parameters and used server-side only; it is never sent to the browser.

Use Cases & Benefits

Verified, Deliverable Addresses

Know before shipping, mailing, or visiting whether an address refers to a real, deliverable place — not after a returned shipment or a failed delivery.

No Vendor Lock-In

The verification workflow, stored fields, and filters belong to the framework, not to Google. If pricing, coverage, or compliance needs change, switch the provider in Settings — users won't notice a difference.

Accurate Geocoordinates in One Step

Latitude and longitude are written from the validation response alongside the address — no separate geocoding call needed. Map views and territory assignments work immediately on verified contacts.

USPS Deliverability for US Contacts

CASS™ processing confirms whether a US address can receive USPS mail and provides the DPV confirmation code — the information needed for compliant, efficient direct mail campaigns.

Audit-Ready Verification Trail

A stored, searchable status on every contact plus a chatter entry for every verification — including coordinate changes — makes data quality auditable without exports or custom reports.

No API Key Exposure in the Browser

Verification calls are made from the Odoo server, not the browser. The key is stored in Odoo system parameters and never sent to the client, keeping credentials secure even on shared or multi-user instances.

What's in the Bundle

Three modules — the shared framework, the Google provider adapter, and the Contacts application module.

Foundation

  1. base_address_validation — Provider registry, verification mixin, generic Verify Address widget and review dialog, provider selection in Settings

Provider Adapter

  1. address_validation_google — Google Address Validation API integration with USPS CASS™/DPV for US & PR, component confirmation levels, and ToS-compliant display-only handling of Google's standardized address (requires base_google_map for the shared Google API key configuration)

Application · Contacts

  1. contacts_address_validation — Verify Address button on the Contact form, severity badge, search filters by verification outcome, automatic status reset, chatter audit trail

Contact Validation Google · Real-time address verification, standardization, and geocoding — directly from the Odoo Contact form, on a provider-agnostic framework.