Address Standardization API Launch
Announcing GoodVat Address Standardization API. 99.5% accuracy, 10ms latency, CRF parsing, and canonical expansions for $5/mo unlimited requests.
We’re building GoodVat to be the most accurate tax calculation engine on the planet — sales tax, VAT, and GST across 14,000+ jurisdictions.
But the first product we’re shipping isn’t tax calculation.
It’s address standardisation.
Here’s why that makes perfect sense — and why it might be the most useful API you didn’t know you needed.
Why a tax company is shipping an address API
Tax calculation sounds simple on the surface: take an address, look up the rate, multiply. But “look up the rate” is where everything falls apart.
In the US alone, there are over 13,000 tax jurisdictions. A single street address can sit inside overlapping layers of:
- State tax
- County tax
- City/municipal tax
- Special purpose districts (transit, school, fire, water)
- Police jurisdiction districts
- Business improvement districts
Getting the right rate means knowing exactly which of those layers an address sits inside. Not approximately. Exactly.
That requires geocoding — resolving an address to a precise rooftop latitude/longitude, then overlaying it against jurisdiction boundary shapefiles.
And geocoding requires clean, structured input.
Garbage in → wrong coordinates → wrong jurisdiction → wrong tax rate → audit liability.
That’s the chain. Address standardisation is the first link.
The Alabama problem
Let’s make this concrete. Consider this customer-entered address from a Shopify checkout:
1200 Main St, Daphne AL 36526Seems simple enough. But Daphne, Alabama sits in Baldwin County, which has:
- Alabama state sales tax:
4.00% - Baldwin County tax:
1.00% - City of Daphne tax:
2.00% - Baldwin County school tax:
1.00%
Combined rate: 8.00%
Now consider an address just two miles down the road:
28150 US Hwy 98, Daphne AL 36526Same ZIP code. Same city name. But this address falls inside the Eastern Shore Metropolitan Planning Organization district and a different special fire district, bumping the combined rate to 9.00%.
A ZIP-code-based tax lookup would have returned the same rate for both. A rooftop geocode against jurisdiction boundaries returns the correct, different rates.
But rooftop geocoding only works if the input address is clean. When a customer types:
1200 main street, daphne alabama, 36526, US…or worse:
1200 Main, Daphne, AL…your geocoder needs structured, canonical components to resolve the right rooftop. That’s what standardisation does.
The pipeline: standardise → geocode → calculate
We’re building GoodVat’s tax engine as three distinct, composable layers:
1. Address Standardisation ← live today
Turn messy, free-form text into structured components. 99.5% accuracy, 10ms p99 latency, 60+ languages, every country on Earth.
$5/month, unlimited requests. Get your API key →
2. USA Geocoding → coming soon
Resolve structured addresses to rooftop coordinates and overlay against jurisdiction shapefiles — fusing OpenAddresses, OpenStreetMap, US Census TIGER/Line, state parcel data, and special-district boundary files.
3. Global Tax Calculation → coming soon
Calculate the exact combined tax rate for any transaction, anywhere in the world, using the geocoded jurisdiction stack. Nexus monitoring, registration, and filing built in.
Each layer is exposed as its own API. Use one, two, or all three. Today we’re shipping the first one.
What the API does
Send a free-form address string. Get back granular structured components and canonical string expansions.
curl -X POST "https://api.goodvat.com/v1/address/normalize" \ -H "Authorization: Bearer $GOODVAT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "query": "781 Franklin Ave Crown Heights Brooklyn NYC NY 11216 USA" }'{ "houseNumber": "781", "road": "Franklin Avenue", "suburb": "Crown Heights", "cityDistrict": "Brooklyn", "state": "NY", "postcode": "11216", "country": "USA", "expansions": [ "781 franklin avenue crown heights brooklyn ny 11216 usa", "781 franklin avenue crown heights brooklyn new york 11216 usa" ]}That’s it. One endpoint. Stateless. 10ms p99 latency. 99.99% uptime SLA.
How it works under the hood
Most address parsers use regex and per-country templates. They work until they don’t — and they don’t a lot.
GoodVat’s standardisation engine treats address parsing as a sequence-labelling problem (the same class of problem as named-entity recognition in NLP). It’s trained on hundreds of millions of real-world addresses across every country and script.
Three composable layers:
Statistical parser (CRF) — A conditional random field sequence model decomposes raw text into semantic components (houseNumber, road, unit, city, state, postcode, country) regardless of word order, language, or formatting convention.
Canonical expansion engine — Standardizes abbreviations and generates a list of fully expanded canonical string variants in expansions: "St" → "Street", "Ave" → "Avenue", "Ste" → "Suite", "Rd" → "Road", directional prefixes ("N" → "North"), and multi-lingual variants. Two different-looking strings for the same address converge on identical canonical expansion strings.
AI resolution layer — For the gnarliest inputs — incomplete addresses, colloquial descriptions, transliterations — an AI layer resolves ambiguity using context, not just pattern-matching.
The result: 99.5% accuracy across 60+ languages and every country on Earth.
The power of the expansions array
Delivering discrete fields like road and postcode is essential for forms and tax calculations. But when engineering teams need to deduplicate databases or build real-time search suggestions, canonical strings in expansions are a superpower:
- Search indexing & typeahead: Index the
expansionsarray in Elasticsearch, Algolia, Meilisearch, or PostgreSQL. A customer searching for"Franklin St"or"Franklin Street"matches instantly without custom synonym tables. - Deterministic deduplication: Hash or join on
expansions[0]to merge duplicate CRM contacts, leads, or real estate listings without brittle fuzzy-matching algorithms. - Cross-system reconciliation: Join records between Stripe, Shopify, Salesforce, and ERP databases with 100% confidence.
Use-cases beyond tax
We built this for tax. But structured addresses and canonical expansions are foundational infrastructure — they show up everywhere a system needs to compare, route, validate, or store a physical location.
Here are the use-cases we’re seeing:
Search suggestions & autocomplete
Index canonical expansions so typeahead search matches whether a user types "st", "street", "ave", or "avenue".
Checkout & shipping validation
Clean customer-entered addresses before a shipping label is printed. Fewer failed deliveries. Fewer “address not found” support tickets.
"123 w elm, ste 4b, san fran CA"→ { houseNumber: "123", road: "West Elm", unit: "Suite 4B", city: "San Francisco", state: "CA", expansions: ["123 west elm street suite 4b san francisco ca usa", ...] }CRM & data hygiene
The same customer address typed five different ways across your CRM, ERP, and support tool. Standardise them all to the same canonical form and your dedup logic actually works.
KYC & identity verification
Standardise address format during signup so identity checks and proof-of-address documents compare apples to apples — not "Flat 2, 14 King's Rd" against "14 Kings Road, Apartment 2".
Geocoding pre-processing
If you’re already using Google Maps, Mapbox, or another geocoder — sending standardised input dramatically improves match rates and precision. Clean input → better coordinates.
Direct mail & marketing
Clean a mailing list before a print run, so postage isn’t wasted on undeliverable addresses and bounce rates stay low.
Fraud & risk scoring
Detect inconsistent or fabricated addresses used to slip past fraud checks. A standardised address that doesn’t decompose into valid components is a strong signal.
Insurance underwriting
Resolve property addresses to structured components so risk is assessed against the correct property, not a fuzzy string match.
Real estate listings
Merge duplicate listings for the same property scraped from multiple sources — even when the addresses were formatted completely differently.
Get started
Everything you need to go from zero to your first standardised address in under two minutes:
Pricing is simple: $5/month, unlimited requests. See pricing →
What’s next
This is the first product in a pipeline. Coming soon:
- USA Geocoding API — Rooftop geocoding fused from 6+ data sources, purpose-built for tax jurisdiction resolution. Refreshed weekly. Join the waitlist →
- Global Tax Calculation API — Sales tax, VAT, and GST calculated across 14,000+ jurisdictions. With nexus monitoring, registration, and filing built in. Join the waitlist →
We’ll also be publishing a series of posts diving deeper into specific address standardisation use-cases — from cutting shipping return rates to building more accurate fraud models. Stay tuned.