Best phone number validation APIs in 2026: a criteria-based comparison

The best phone number validation API depends on the job. Forms need format and line type, SMS senders need live reachability, account-security teams need SIM-swap data, and channel routing needs messaging-app presence. No single API leads on all four. The table below compares eight APIs on public, dated evidence and says where each one is strongest.

Disclosure: we make MobileValidate, one of the APIs compared. Every competitor fact below comes from the provider's own public pricing or documentation page, fetched on 26 September 2026 and linked. We re-checked every list price on 3 November 2026, and none had changed. Prices are USD list prices before discounts. Where a provider doesn't publish a price or a policy, we say so rather than guess. We'll refresh this page every quarter. If you spot an error, tell us and we'll fix it.

What should a phone validation API return in 2026?

"Phone validation" covers five different questions. Decide which ones you need before comparing providers:

Then weigh the criteria that separate good APIs from cheap ones: coverage per country, what you pay for unknown answers, latency, freshness, privacy and developer tooling. Our buyer's checklist explains each criterion in depth. This page applies the criteria to real products.

How do the leading APIs compare?

Main data offered, list price for 10,000 carrier and line type lookups, and what the public pages say about billing for failed lookups. "Not stated" means we couldn't find it on a public page, not that the provider lacks a policy.

Our own figures are our prices on 6 November 2026 (unchanged since 17 October 2026); current prices are on the pricing page and in our live catalog (GET /v1/services). IPQualityScore is left out because its pricing and docs returned HTTP 403 when we fetched them.

Developer tooling, from the same pages:

Where is each API strongest?

A fair summary, based on the tables above:

We make no accuracy claims for anyone, including ourselves. Headline accuracy figures are not comparable across providers, and "99% accurate" means nothing without the country, the sample and the definition of unknown. Measure accuracy yourself, with the bake-off below.

Which is best for sign-up forms?

For forms, you need three things: fast format validation, line type (to spot VoIP or landlines where you expect a mobile), and predictable cost at peak traffic.

• Start free. Validate format and normalize to E.164 in your own code with a maintained library before calling any API. Our phone validation in code guide shows how.
• Add line type on the server side. Telnyx ($0.0025), MobileValidate ($0.003 real time from 17 October 2026, beta) and Plivo ($0.004) have the lowest public per-request prices for carrier and line type in this comparison. Veriphone is cheapest if you only need validity and carrier from reference data.
• Mind what failures cost. Forms receive junk input. If every request is billed, including invalid input, bot traffic becomes an expense. Check each provider's policy. Abstract states that invalid input uses a credit, Veriphone doesn't charge for input that isn't a phone number, and we don't charge for invalid numbers or unknown answers.

Use line type as a reason for an extra step, not an automatic block. Many real users have VoIP numbers (VoIP detection at sign-up).

Which is best for SMS cost reduction?

To cut SMS spend, you need to drop numbers that can't receive a message before you send: landlines, unallocated ranges and, ideally, disconnected numbers.

• Line type removes landlines and toll-free numbers. Every API here offers it.
• Live status catches mobile numbers that are switched off or no longer in service. Among the APIs compared here, Abstract documents a line status field and Telesign lists deactivation status. Our HLR lookup returns reachable, unreachable or not assigned for mobile numbers, billed per conclusive answer (current price), with unknown answers free.
• Channel choice is the other lever. Sending an OTP on WhatsApp where the user has it can cost less than SMS in many markets (WhatsApp OTP vs SMS OTP). Messaging-app presence checks are where MobileValidate is different: WhatsApp from $0.25 per 1,000 numbers in bulk ($0.00025 each), and Telegram, Viber and other apps in the same bulk job.

For bulk list cleaning, compare cost per conclusive answer, not per request. A cheap lookup that returns unknown for a third of your list, and bills it, costs more than it looks. Our bulk list-cleaning guide walks through it.

Which is best for choosing a messaging channel?

To decide whether to send a code or a notification by SMS, WhatsApp or another app, you need to know which apps the number is registered on. Of the other APIs in this comparison, only Abstract lists "messaging" data, and its documentation shows that as the carrier's email-to-SMS gateway address, not app registration. The others don't list messaging-app presence at all. So this is the job where MobileValidate is the clearest option here.

One request or bulk job can combine several checks. List prices per number (our prices on 6 November 2026; see pricing for current prices):

Bulk prices apply per country in a job. WhatsApp checks get the bulk price for groups of at least 132 numbers from one country; smaller groups are priced at the real-time price. Bulk-only checks such as Viber and RCS are billed at least the price of 500 checks for each country that returns an answer, so a short list spread over many countries costs more per number. The free estimate shows both before a job runs.

Each check answers registered: true, false or null (unknown) with a checked_at time. Unknown answers, unsupported countries, timeouts, invalid numbers and duplicates are not billed, and repeat checks inside the freshness window come from your account's cache for free. The checks never return names, photos or profiles. They say whether an account exists, nothing more.

The limits, stated plainly: presence is not activity (a registered account may be rarely used), answers can be unknown, and some checks run in bulk only. Our channel selection page shows the routing flow.

Which is best for account-takeover defence?

Not us. Account-takeover defence depends on ownership signals: was the SIM swapped recently, does the number still belong to this person, has it been reassigned? MobileValidate doesn't sell SIM-swap, identity-match or reassigned-number data.

The APIs to evaluate for this job:

• Telesign Phone ID: SIM-swapped, ported-out and call-forwarded signals.
• Sinch: SIM swap (beta, US/CA) and the US Reassigned Numbers Database (beta).

Operators also expose these signals directly through the CAMARA open APIs. SimSwap's latest release is r4.3 (sim-swap API v2.2.0, 30 October 2026), and NumberVerification's is r4.2 (API v2.1.1, 19 October 2026) (CAMARA SimSwap; CAMARA NumberVerification). Availability depends on the operator and the aggregator you contract with. Our SIM-swap fraud signals post explains how to use them.

Where we fit in this flow: as a cheap first filter (line type, messaging-app presence) before a paid ownership check. Not as a replacement for one.

Which is best for AI agents (MCP)?

If an AI agent will call the API, look at more than "has an MCP server". Check three things:

1. Does the server call the API, or only search the docs? Plivo's server and one of Sinch's servers are documentation-only. Telnyx, Sinch, Veriphone and MobileValidate publish servers that make real calls.
2. Can you cap spend? An agent in a loop can burn through credit. Look for scoped keys with daily spend caps and a confirmation step for large calls.
3. Is the output structured? Agents act on true, false and null, not on free text.

Our MCP server accepts only agent keys (scoped and spend-capped) and test keys, never live keys. Calls above a confirmation threshold (USD 1.00 by default) must be repeated with the confirmed amount. For agents, that design matters more than the price per lookup. If your agent needs SIM-swap data, pair a Sinch server with a capped key of your own.

How do I run a fair bake-off?

Test two or three candidates on the same labelled sample: a few hundred numbers you hold with a lawful basis, across your main countries, where you know the truth (recent deliveries, confirmed mobiles, known landlines). Measure the unknown rate, agreement with your labels and latency.

Node.js (18+). Each provider gets a small adapter that returns true, false or null:

// bakeoff.mjs: node bakeoff.mjs sample.csv   (CSV: e164,label  where label is mobile|not_mobile)
import { readFileSync } from "node:fs";

const providers = {
  mobilevalidate: async (e164) => {
    const r = await fetch("https://api.mobilevalidate.com/v1/lookup", {
      method: "POST",
      headers: { Authorization: `Bearer ${process.env.MOBILEVALIDATE_API_KEY}`, "Content-Type": "application/json" },
      body: JSON.stringify({ numbers: [e164], checks: ["carrier"], wait: 10 }),
    }).then((x) => x.json());
    const c = r.results?.[0]?.checks?.["network.carrier"]; // pending or unknown → null
    const lt = c?.status === "completed" ? c.attributes?.line_type : null;
    return lt == null ? null : lt === "mobile";
  },
  // other: async (e164) => { /* call the other provider, return true / false / null */ },
};

const rows = readFileSync(process.argv[2], "utf8").trim().split("\n").slice(1).map((l) => l.split(","));
for (const [name, check] of Object.entries(providers)) {
  let unknown = 0, agree = 0, known = 0; const ms = [];
  for (const [e164, label] of rows) {
    const t = performance.now();
    const v = await check(e164).catch(() => null);
    ms.push(performance.now() - t);
    if (v === null) { unknown++; continue; }
    known++; if (v === (label === "mobile")) agree++;
  }
  ms.sort((a, b) => a - b);
  console.log(name, { n: rows.length, unknownRate: unknown / rows.length, agreement: known ? agree / known : null,
    p50ms: Math.round(ms[Math.floor(ms.length * 0.5)]), p95ms: Math.round(ms[Math.floor(ms.length * 0.95)]) });
}

Python (3.9+), same idea:

# bakeoff.py: python bakeoff.py sample.csv
import csv, os, statistics, sys, time
import httpx

def mobilevalidate(e164):
    r = httpx.post("https://api.mobilevalidate.com/v1/lookup", timeout=30,
                   headers={"Authorization": f"Bearer {os.environ['MOBILEVALIDATE_API_KEY']}"},
                   json={"numbers": [e164], "checks": ["carrier"], "wait": 10}).json()
    c = ((r.get("results") or [{}])[0].get("checks") or {}).get("network.carrier") or {}  # pending or unknown -> None
    lt = (c.get("attributes") or {}).get("line_type") if c.get("status") == "completed" else None
    return None if lt is None else lt == "mobile"

PROVIDERS = {"mobilevalidate": mobilevalidate}  # add adapters for the providers you test

rows = list(csv.DictReader(open(sys.argv[1])))
for name, check in PROVIDERS.items():
    unknown = agree = known = 0; ms = []
    for row in rows:
        t = time.perf_counter()
        try: v = check(row["e164"])
        except Exception: v = None
        ms.append((time.perf_counter() - t) * 1000)
        if v is None: unknown += 1; continue
        known += 1; agree += v == (row["label"] == "mobile")
    q = statistics.quantiles(ms, n=20)
    print(name, dict(n=len(rows), unknown_rate=unknown / len(rows), agreement=agree / known if known else None,
                     p50_ms=round(statistics.median(ms)), p95_ms=round(q[18])))

Check the response shape against each provider's docs before trusting the numbers. Our lookups reference documents ours. Then compare cost per conclusive answer: the invoice total divided by the answers that weren't unknown. Run the test from the region your servers are in, at the time of day your traffic peaks. Test keys return fixed answers, so use live keys on your labelled sample for the real measurement. For a quick spot check first, every account can run up to 5 phone numbers and 5 e-mail addresses through the real-time checks for free on the dashboard's Try it page.

How did we build this comparison?

We followed a fixed method so the table can be checked and repeated:

1. Criteria first. The five questions and the criteria come from our buyer's checklist, written before any provider was scored.
2. Public sources only. Every competitor fact comes from the provider's own pricing or documentation page, fetched on 26 September 2026 and linked in the table. We didn't use third-party roundups or competitors' comparison tables about each other.
3. List prices, like for like. "10,000 lookups" means the list price for 10,000 carrier and line type lookups, or the smallest monthly plan that covers them. Volume discounts, contracts and taxes are excluded.
4. No guessing. Where a page didn't state a price or a policy, the cell says "not stated", "not public" or "not verified".
5. Exclusions. We left out providers whose pages we couldn't fetch, and providers whose main product is outside phone validation. Absence from the table is not a judgement.
6. Our own row uses the same rules. Our prices come from the live catalog, and the rows where we are weaker (SIM swap, identity, live status) are shown as they are.

Prices and features change often. We'll re-fetch every source each quarter and update the date at the top.

What are the key takeaways?

• Pick by job: format and line type for forms, live status for SMS cost, ownership signals (SIM swap, identity, reassignment) for account security, messaging-app presence for channel choice.
• On public list prices fetched on 26 September 2026, 10,000 carrier and line type lookups from the other APIs compared cost from $25 (Telnyx) to $110 (Telesign Phone ID); ours cost $30 in real time (beta) at our prices from 17 October 2026.
• Most providers don't publish whether failed lookups are billed. Ask, and check your first invoice.
• For SIM swap, identity match and reassigned numbers, evaluate Telesign, Sinch or CAMARA-based operator APIs. MobileValidate doesn't offer these.
• MobileValidate is strongest for messaging-app presence plus carrier in one request, with unknown results free and a spend-capped MCP server. Run the bake-off on your own numbers before you decide.