Validate a phone number
Exactphone_validateDeterministic and authoritative — the canonical answer for this input.
Validate a phone number and return its type (mobile, fixed_line, toll_free, voip, etc.), ITU country code, ISO region code, and E.164 normalization. Any dialing extension ('...ext 22') is captured in a separate `extension` field, since E.164 drops it. Backed by Google's libphonenumber. Default country hint is 'US' - pass country_hint with an ISO 3166-1 alpha-2 code to parse non-US numbers that lack a leading '+'. Invalid numbers return confidence=0.0 with a reason, not an error. Processing multiple inputs? Use `phone_validate_batch` to do up to 1000 in one call.
Parameters
valuestringrequiredPhone number to validate.
country_hintstringoptionalISO 3166-1 alpha-2 country code used to parse the number when it lacks a leading '+' (e.g. 'US', 'GB', 'CA', 'AU'). Default 'US'. Ignored for numbers already in E.164 format.
Call it
curl -X POST https://api.snipget.ai/v1/phone/validate \
-H "Authorization: Bearer sk_live_..." \
-H "Content-Type: application/json" \
-d '{"value":"(212) 456-7890"}'The Batch tab sends up to 1000 inputs in one call via /v1/phone/validate/batch.
Example response
{
"input": "(212) 456-7890",
"is_valid": true,
"is_possible": true,
"country_code": 1,
"region_code": "US",
"type": "fixed_line_or_mobile",
"normalized_e164": "+12124567890",
"extension": null
}FAQ
What does this tell me?
Whether a phone number is actually a valid, dialable number for its region, plus its country code, region, line type (mobile, fixed line, toll-free, voip, and so on), and its clean +country-code form. It is the easy way to filter junk numbers out of a list before you call or text them.
What about a dialing extension?
If the input carries an extension (for example "314.555.0198 ext 22"), it is returned in a separate extension field ("22"). The E.164 form drops extensions, so this is the only place it survives - keep it if you are normalizing numbers for round-trip use.
Why use this instead of a regex or my own check?
Valid numbering rules differ by country and change over time. This is backed by Google's libphonenumber, the same data phones use, so it catches numbers that look fine but are not real far more reliably than a hand-written pattern or a model guess.
How do I check a non-US number?
Pass country_hint with the two-letter country code (for example {"value": "02071838750", "country_hint": "GB"}) for numbers that do not start with a plus sign. Numbers already in +country-code form, like +442071838750, are detected automatically.
Is the answer authoritative?
Yes. Validation is exact and deterministic against maintained numbering rules, so the same number always gets the same verdict. A valid number returns confidence 1.0, and a number that is the right length but not a real assignment returns confidence 0.5 with is_possible true.
What happens with bad input?
It never errors on bad data. Something that is not a phone number returns is_valid false with confidence 0 and a reason, so you can flag it without your workflow breaking. Note this confirms a number is well-formed and assignable, not that it is currently in service for a specific person.