# Phone Validation Database Accuracy Comparison: What You Need to Know > Compare phone validation database accuracy across providers. Learn which metrics matter and how to choose the right validation API for your business needs. Published 2026-03-25, updated 2026-10-03 by Marcus Whelan. Canonical: https://checkthatphone.com/blog/phone-validation-database-accuracy-comparison-what-you-need-to-know Every validation provider claims high accuracy on their pricing page. That number tells you almost nothing. What matters is how the database performs on the cases that are hard: a number ported last week, a Google Voice line, a block of area codes allocated three months ago. Run the same test set through a few APIs side by side and the carrier field won't always agree on the ported numbers. That gap is where your failed deliveries and missed fraud signals come from, and it's invisible until you go looking for it. This is how I'd actually compare providers, and why the metrics on the marketing site aren't the ones that decide it. ## Why a few points of accuracy is a lot A validation database feeds your communications, your fraud checks, and your reporting. When it's wrong, the failures stack up: - Messages go to disconnected numbers, wasting spend and dragging down your engagement metrics - Stale carrier and line type data leaves gaps that fraudsters walk right through - Valid customers get rejected on a false positive and abandon the transaction - SMS campaigns hit invalid numbers and return nothing The arithmetic is simple: on 100,000 sends, a 2% accuracy difference is 2,000 failed deliveries. That's not a rounding error, it's a line item. ## The metrics that actually separate providers ### Data freshness The most important question about a database is how often it updates, and daily or real-time is the bar. North American numbering changes every single day: porting, carrier mergers, new allocations. A provider refreshing weekly or monthly is already behind on every number ported since its last update. Every CheckThatPhone lookup runs a live carrier dip at lookup time, so [our validation API](/docs) reflects each number's current carrier and porting status rather than a snapshot. [Carrier lookup](/carrier-lookup-api) shows what that returns. ### Line type precision Telling mobile from landline from VoIP from toll-free sounds trivial. It isn't: - A number first assigned as a landline may now route to a mobile device through a VoIP service - Mobile numbers get ported to VoIP providers - Some databases lazily classify every ported number by its original assignment, which is just wrong Test this directly. Throw ported numbers, Google Voice lines, and freshly allocated blocks at each provider and see who gets them right. The spread between providers here is wider than anywhere else. The classification itself can also cost you contactable numbers. Some US and Canada numbers labeled "landline" accept SMS through a hosted messaging provider (about 7% of the landlines we check are SMS-capable), and a database that flags them by their original assignment leads you to discard reachable contacts. CheckThatPhone offers landline SMS reachability as an opt-in add-on (one extra credit per lookup) that checks which "landline" numbers can actually receive a text. Mobile numbers skip the check, so you only pay where it applies. That depth only works on fresh data: a stale database can't tell you that last quarter's landline is textable today. ### Geographic reliability Area codes stopped guaranteeing location years ago, thanks to porting and VoIP. Real geolocation has to account for: - Original allocation: rate center, state, city - Current carrier routing - The difference between where the number is billed and where it's actually used If you route by region or have a regional compliance requirement, confirm the provider clearly separates original allocation geography from current service location. A provider that conflates the two will quietly route calls to the wrong place. ## Test it yourself before you commit Vendor benchmarks are marketing. Run your own. ### Build a test set Put together 100 to 200 numbers that mirror your real traffic: - Recently ported mobile numbers (30-40%) - VoIP numbers from major providers (15-20%) - Landlines across different markets (20-25%) - Invalid or disconnected numbers (10-15%) - Edge cases: newly allocated blocks, rural carriers (10-15%) ### Run it through several APIs Push the same set through 3-4 providers and compare: - Do the carrier results match the real carrier? - Does line type detection match real behavior? - Are disconnected numbers actually caught? - How far apart are the results on recently ported numbers? ### Check against ground truth The only honest accuracy test uses numbers where you already know the answer. Call or text them and confirm they behave the way the API says. It's tedious. It's also the only step that can't be faked, so don't skip it. ## What to look at beyond basic validation ### Portability Porting patterns carry signal, and a number that keeps changing carriers is worth a second look. CheckThatPhone's API returns the current porting status (`dipPorted`) and routing number (`dipLrn`), not a porting history, so to see repeated ports you store each lookup's carrier and compare over time. That's still useful input for fraud scoring. ### TCPA litigator exposure Accuracy isn't only about whether a number is live; it's also about whether texting it puts you at risk. CheckThatPhone offers a TCPA litigator scrub as an opt-in add-on (one extra credit per lookup) that checks each US and Canada number against a database of known serial TCPA plaintiffs and repeat filers, refreshed daily. On a match it returns the litigator's name and type and rewrites the API's `action` field to `unsubscribe`, so a single response tells you to leave that number alone. This is the clearest case for fresh, deep data: new plaintiffs surface constantly, and a list that hasn't been refreshed is the one that lets a known plaintiff back into your campaign. Two separate free flags, `dncState` and `dncComplainer`, add state do-not-call registry and complainer-list checks to the same lookup. ### Carrier detail Knowing the exact carrier, not a generic bucket, lets you: - Route messages for better deliverability - Pick carrier-specific formatting and protocols - Cut cost by routing through preferred partners Favor providers that give you specific carrier names over vague categories. ### Real-time or batch Some flows need an answer at the point of entry; others are fine processing in bulk overnight. Check whether a provider supports both, and whether accuracy holds across the two. CheckThatPhone runs the same lookup either way: the real-time API, or a [bulk CSV upload](/bulk-phone-validation) from the dashboard. Real-time lookups usually carry the freshest data at the cost of some latency. ## How to choose When you line up the candidates, weigh: 1. Update frequency: daily or real-time is the floor 2. Data sources: multiple authoritative sources beat a single feed for coverage 3. Accuracy claims you can test: ask how a provider measures accuracy, then check it against your own test set 4. Documentation: clear [API documentation](/docs) is a decent proxy for how mature the service is 5. Pricing fit: a [pricing model](/pricing) that matches your usage without forcing a trade-off on accuracy For the rest of the checklist, see [choosing a phone validation API: 7 features to look for](/blog/choosing-phone-validation-api-features), and for what each provider charges, the [phone validation API pricing comparison](/blog/phone-validation-api-pricing-comparison). ## Keep measuring after you pick Accuracy isn't a one-time bake-off. Once you're live: - Track false positive and false negative rates month over month - Watch deliverability metrics before and after validation - Re-run your edge cases quarterly, because the numbering rules keep shifting - Compare real customer feedback against what the API told you The point is that accuracy moves your numbers directly: better deliverability, fewer fraud losses, less friction for real customers. Build a test set that looks like your traffic, run it against a few providers including CheckThatPhone, and verify the hard cases against ground truth. The [API documentation](/docs) and [pricing options](/pricing) are there when you're ready to set it up. --- CheckThatPhone is a phone validation API for US and Canada numbers: https://checkthatphone.com (docs: https://checkthatphone.com/docs.md, pricing: https://checkthatphone.com/pricing.md).