Contact Validation Products for Odoo

All modules target Odoo 19.0 and work on both Community and Enterprise editions. There is no dependency on any Enterprise-only feature — the suite is built entirely on standard Odoo framework APIs.

Yes — one account with the provider you choose:

• Google — a Google Cloud account with billing enabled and the Address Validation API activated
• PostGrid — a PostGrid account with an Address Verification subscription (US/CA and/or International)
• Smarty — a Smarty account with a US Street Address and/or International Street Address subscription

Provider usage is billed by the provider directly, per their own pricing. The modules themselves add no per-lookup fee.

The Odoo server needs outbound access to the selected provider's API endpoints. The user's browser does not talk to any provider — all verification requests are made server-side, and credentials never reach the browser.

No — beyond a standard Odoo 19.0 deployment with the Python requests library, which ships with virtually every Odoo installation. No PostGIS, no extra services.

No — install only the adapter you need. The Address Validation section in Settings lists all three providers with a checkbox each; checking one installs the adapter automatically. With a single adapter installed it is used implicitly; with several, you pick the active provider from a dropdown.

Yes — that is the core design goal. The button, dialog, stored fields, and search filters belong to the shared framework, not to any provider. Switching means installing the new adapter, entering its credentials, and selecting it in Settings. Existing verification verdicts are kept; new verifications use the new provider.

The provider selection is cleared automatically and contacts verified by that provider fall back to Not Verified — nothing breaks. Install another adapter (or reinstall the same one) and verification resumes immediately.

The framework depends only on base_setup and web; the Contacts module additionally requires contacts and base_geolocalize. All are part of the standard Odoo Community distribution.

The Google adapter also requires base_google_map (from the Google Maps Suite), which provides the shared Google API key configuration.

In Odoo system parameters (ir.config_parameter), entered through each provider's section in Settings → General Settings → Address Validation. Credentials are used exclusively server-side and are never sent to the browser.

Use API restrictions (limit the key to the Address Validation API) combined with an IP allowlist of your server's egress address, or no application restriction plus usage quotas if your host has no static IP (e.g. Odoo.sh).

With PostGrid, yes — enter a test key and leave live mode off. Test keys return mock data through the exact same workflow, and sandbox results are clearly marked in the dialog and chatter so they can never be mistaken for real verifications.

Google and Smarty do not offer mock modes, but both have free monthly usage tiers that comfortably cover evaluation.

Pending form edits are saved, the address is sent server-side to the active provider, and a review dialog opens with the provider's verdict explained in plain language, a side-by-side comparison of entered vs. standardized address, USPS DPV confirmation where applicable, and provider-specific details. The user then chooses: Apply Standardized Address (writes address + coordinates), Keep Current Address (stores only the verdict), or Discard.

Each provider's status is stored verbatim — Google's Valid / Needs Review / Invalid, PostGrid's Verified / Corrected / Failed, Smarty's delivery-point DPV statuses. On top of that, every verdict carries a shared severity (green / yellow / red) that drives the badge colors and the built-in search filters — so you can audit the whole database consistently even if different contacts were verified by different providers.

It depends on the provider's terms, and the framework enforces this automatically. PostGrid and Smarty permit permanent storage, so their standardized addresses are kept on the record. Google's terms do not — its standardized address is shown for review only, and what gets saved is always the address the user explicitly confirms in the dialog.

The verification status resets to Not Verified automatically — whether the edit happens in the form or through a server-side write. A stale "verified" badge can never survive an address change.

Yes — every verification posts a chatter message on the contact with the provider, the verbatim status and its explanation, the DPV code where applicable, and old → new coordinates when they change. Combined with the stored status fields and search filters, address quality becomes fully auditable inside Odoo.

All modules are licensed under the Odoo Proprietary License v1.0 (OPL-1). A purchased license grants you the right to use and modify the modules for your own deployments; redistribution or resale of the code is not permitted.

The main ongoing cost is your validation provider account — Google, PostGrid, and Smarty each bill per lookup under their own pricing, and each offers a free tier or trial suitable for evaluation. The modules add no per-lookup fee on top.

Yes — with a valid license per the OPL-1 terms. Each client deployment needs its own provider account and credentials, since provider usage is billed per account. Contact us for partner and multi-deployment arrangements.

Yes — the framework is built for it. Any model can inherit the address.validation.mixin to gain the full workflow: verification fields, the Verify Address widget, the review dialog, reset lifecycle, and chatter logging. Address and coordinate field names are configurable per model, so the mixin works even when your model's fields don't match res.partner's naming.

Yes — providers are adapters registered against a documented contract: a server-side service model implementing verify(), status interpretation hooks, and a storage-policy flag. The generic widget and dialog render any provider's normalized result without JavaScript changes, so a new provider (Loqate, Melissa, HERE, a national postal API) is a Python-only module.

Everything follows standard Odoo conventions:

• All provider communication in Python service models — no API calls from the browser
• Credentials in ir.config_parameter, configured through standard Settings sections
• All frontend components in OWL — Odoo's standard JavaScript framework
• No monkey-patching of core Odoo code
• Only the standard Python requests library — no exotic dependencies

Yes — every module ships its own test suite: transport and parsing tests for each provider service (with the provider API mocked), end-to-end flow tests for the Contacts integration, and contract tests that pin the normalized result shape each provider must return. The suite runs in CI against a fresh Odoo 19 database on every change.