On the record, as it is filled
Addresses get suggested and formatted as you type, with autocomplete, before anyone saves.
Clean
Know which addresses actually work
Your CRM stores whatever was typed in. It cannot tell you if an address is real. Verification checks it and saves the result on the record.
What changes once addresses are checked
Before Plauti
- Mail and shipments bounce back because the address was never real.
- Addresses arrive in a dozen formats, with street, city, and postal order all over the place.
- Nothing on the record says whether an address was ever checked.
WithPlauti
- Bad addresses get flagged before anything ships.
- Every address lands in the format the destination country expects, automatically.
- The result and the check date sit in fields you own.
What we check
Each check saves the result, a standardized version of the address, and the date it ran.
Addresses
Checks the address is real, then writes it the way that country writes addresses. Works in 240+ countries. Coordinates optional.
Records you already have
Run a job over the records already in your CRM. Filter which ones, and schedule it to repeat.
Where verification runs
Batch jobs over existing records
Filter the record set, pick the addresses to check, then let auto-process handle the outcome, fixed where it can be, flagged where it can't.
Status, value and date on every record
Results land in fields you choose, one per check. "Is this address deliverable, and when did we last check?" becomes a question the record can answer on its own.
Reporting with the tools you already have
The outputs are ordinary fields, so coverage and error-rate dashboards live in your CRM's own report builder, no separate tool, no second data store.
Your automations, and forms
Verification runs inside your own automations, and the same rules apply to web forms and portals before that address ever becomes a record.
Does it work the way you need it to?
The four things admins check before running this on real data.
Scope and permissions
You choose which records and fields to check, and which checks run on each. Your existing profiles, permission sets, and sharing rules apply as they are.
- Works on standard and custom record types.
- Results go into fields you own.
- Separate access for running jobs and checking single records.
What leaves your CRM
Only the field being checked goes to a specialist partner. The result comes back and is written to the record.
- No bulk export, no copy of your CRM held outside it.
- We cannot guarantee a region for address checks.
What a check costs
Ten credits per address checked, fourteen with coordinates.
- Same cost however the record came in.
- Checking an address again costs again.
- Use the validation date to decide when.
Running it at volume
Jobs work through your existing records in batches, and can repeat on a schedule.
- Large runs take time, so plan them outside busy hours.
- Keep them clear of heavy integration windows.
- Users running jobs need API access switched on.
Frequently asked questions
Isn't this what a validation rule already does?
No. A validation rule checks that a field is filled in and looks roughly right. It cannot tell you whether an address actually exists. Verification checks that, on new records and existing ones.
What exactly gets checked?
Whether the address is real, then it's written the way that country writes addresses, in 240+ countries, with coordinates as an option.
Does our data leave the CRM?
Only the phone number being checked goes to a specialist partner for the check itself; the result is written straight back to the record.
Can it check the numbers already in our database?
Yes, batch jobs run over existing records, filtered however you choose, and can repeat on a schedule.
What does a check cost?
Ten credits per address checked, fourteen with coordinates, regardless of how the record came in.
See how it works
Talk with one of our experts to see how that works for your use case.