API for phone validation

You have phone numbers coming in from forms, checkouts, and CRMs, and you need to know if they’re valid, mobile or not, which country they belong to, and how to format them correctly before you ship. By the end of this article, you’ll validate a phone number and extract carrier, country, line type, standard formats (E.164, international, national), time zones, and more using a single HTTP GET request.

What this API returns and when to use it

The Phone Validator API provides instant validation and rich metadata for a given phone number. You pass one parameter (the phone number) and receive fields like:

is_valid, is_possible: validation flags you can gate flows on
provider, line_type, is_mobile: routing and messaging-channel decisions
country, country_code, country_iso2/3, continent, country_flag: localization and compliance
format_national, format_e164, format_international, format_rfc3966: storage and display formats
time_zones, utc_offset: messaging windows and scheduling
currency_code, location, national_number: enrichment for billing or CRM

Common uses include sign-up form validation, SMS deliverability checks, phone normalization in user databases, country-aware customer routing, and time zone–aware messaging.

Getting started on Zyla API Hub

The API is available on Zyla API Hub, an API marketplace with a single account, one API key, and a subscription + quota model across more than 10,000 public APIs. To get going:

Open the listing: Start 7-day trial on Phone Validator API.
Click Subscribe (or start the 7-day trial when available) and get your API key. There is no Free Plan; access is subscription + quota, not pay-per-call. Check the API page for current access options and pricing.
Call the endpoint with Authorization: Bearer YOUR_API_KEY.

Endpoint you’ll use

This API exposes one straightforward read endpoint.

Method: GET
URL: https://zylalabs.com/api/10138/phone-validator-api/26579/phone-validation
Query parameters:
- phone (string, required): a phone number, e.g., +41799530236

cURL example (copy/paste)

curl -s -X GET "https://zylalabs.com/api/10138/phone-validator-api/26579/phone-validation?phone=%2B41799530236" \
  -H "Authorization: Bearer YOUR_API_KEY"

Official sample response

{
    "is_valid": true,
    "is_disposable": false,
    "provider": "Swisscom",
    "location": "Switzerland",
    "country": "Switzerland",
    "country_iso2": "CH",
    "country_iso3": "CHE",
    "country_code": 41,
    "continent": "Europe",
    "time_zones": [
        "Europe/Zurich"
    ],
    "format_national": "079 953 02 36",
    "format_e164": "+41799530236",
    "format_international": "+41 79 953 02 36",
    "format_rfc3966": "tel:+41-79-953-02-36",
    "line_type": "mobile",
    "is_mobile": true,
    "is_possible": true,
    "national_number": "799530236",
    "country_flag": "🇨🇭",
    "currency_code": "CHF",
    "utc_offset": "+02:00"
}

What you’ll likely use first:

is_valid and is_possible to accept or reject input at the edge
format_e164 for canonical storage (single source of truth)
line_type and is_mobile to gate SMS vs. voice vs. WhatsApp
country_iso2, country_code, and time_zones/utc_offset for routing and scheduling
provider for carrier-specific rules or downstream enrichment

Python example: validate and normalize a phone number

This example calls the same endpoint, checks validity, then stores E.164 format and some metadata you might want in your user profile.

import requests

API_URL = "https://zylalabs.com/api/10138/phone-validator-api/26579/phone-validation"
API_KEY = "YOUR_API_KEY"

def validate_phone(phone: str) -> dict:
params = {"phone": phone}
headers = {"Authorization": f"Bearer {API_KEY}"}
resp = requests.get(API_URL, params=params, headers=headers, timeout=10)
resp.raise_for_status()
data = resp.json()

# Minimal checks for gating signups or sending OTPs
if not data.get("is_valid") or not data.get("is_possible"):
return {
"accepted": False,
"reason": "Invalid or impossible number",
"raw": data
}

normalized = {
"accepted": True,
"e164": data.get("format_e164"),
"national": data.get("format_national"),
"international": data.get("format_international"),
"rfc3966": data.get("format_rfc3966"),
"is_mobile": data.get("is_mobile"),
"line_type": data.get("line_type"),
"carrier": data.get("provider"),
"country": data.get("country"),
"country_iso2": data.get("country_iso2"),
"country_code": data.get("country_code"),
"continent": data.get("continent"),
"time_zones": data.get("time_zones"),
"utc_offset": data.get("utc_offset"),
"currency_code": data.get("currency_code"),
"national_number": data.get("national_number"),
"country_flag": data.get("country_flag"),
"is_disposable": data.get("is_disposable"),
}
return normalized

if __name__ == "__main__":
result = validate_phone("+41799530236")
print(result)

Implementation notes that save time

Canonical storage: Use format_e164 as the canonical phone field. Keep the original input separately if you need auditability or UX re-display.
Display vs. dial: Show format_national to users in the same country; use format_international for cross-border display; use E.164 to dial or send messages programmatically.
Scheduling messages: Use time_zones and utc_offset to suppress messages during off-hours. Store both alongside the user so you can schedule without revalidating on every send.
Country gating: If your product has country restrictions, gate during signup with country_iso2 and country_code.
Channel selection: Use is_mobile and line_type to choose SMS, voice, or alternative channels.
Caching: Cache successful lookups by E.164 for a reasonable window to reduce latency and quota usage for frequently-contacted numbers.
Error handling: Treat non-2xx as transient or permanent depending on context. For synchronous user actions (e.g., OTP), return a readable message; for batch jobs, retry with backoff.

End-to-end flows you can ship this week

Signup form: validate on submit

On form submit, send the entered number to the endpoint.
Reject if is_valid or is_possible is false. Display format_national to show the corrected format.
Store format_e164, country_iso2, and line_type for downstream flows.

Messaging routing: pick the right channel

Look at is_mobile and line_type to determine SMS eligibility.
Use provider if you have carrier-based sending rules.
Throttle or schedule by time_zones/utc_offset to respect local hours.

CRM enrichment: standardize numbers across systems

Batch through your phone fields, calling the API for each unique number.
Replace inconsistent formats with format_e164 and keep national_number for UI search or local dials.
Add country_iso2 and currency_code to enable region-specific operations and reporting.

Calling via MCP from AI agents

You can route calls through Zyla’s MCP endpoint, which works with Claude Code, Cursor, Windsurf, and other MCP-compatible clients. Configure your agent or client to reach:

MCP

Provide your Zyla API key (apikey=YOUR_API_KEY) to the MCP endpoint. From there, your agent can invoke the same Phone Validator API operation without embedding raw HTTP logic in your prompts. This is useful when you want an assistant to validate user-provided numbers during a chat or code session.

Production checklist

Authentication: send Authorization: Bearer YOUR_API_KEY on every request.
Input normalization: accept user input with or without a leading +, but always store format_e164.
Privacy: treat phone numbers as PII. Log minimally and redact in traces.
Idempotency: de-duplicate calls by E.164 in your queue workers to avoid double-charging quota.
Observability: log is_valid, is_possible, line_type distribution to catch anomalies in intake.
Fallback UX: on API timeouts, let users proceed with a warning or prompt to confirm the number.

Troubleshooting tips

Unexpected 401/403: ensure the Authorization header uses Bearer YOUR_API_KEY and the key is active for your subscription.
No data returned: check that the phone parameter is URL-encoded and includes a country prefix when available.
Formatting mismatch: prefer the API’s canonical format_e164 over local client formatting libraries for consistency.

Reference: endpoint details

Phone Validation

Method: GET
URL: https://zylalabs.com/api/10138/phone-validator-api/26579/phone-validation
Query parameter: phone (string, required)
Auth header: Authorization: Bearer YOUR_API_KEY
Returns: validation flags, carrier, country and ISO codes, continent, time zones and UTC offset, national and international formats, RFC3966 URI, line type, mobile flag, national number, country flag, and currency code.

How to evaluate cost and access

Access is subscription + quota, not pay-per-call. There is no Free Plan. A 7-day trial may be available; check the listing for current options. If you’re testing a new flow, start with the trial, deploy behind a feature flag, and monitor quota usage before ramping traffic.

FAQ

Does the API accept numbers without a leading +?
Pass the phone parameter as you receive it, but for reliable results include the country code (e.g., +41...). The response provides standardized formats, including E.164.

Which format should I store in my database?
Store format_e164 as the canonical value. Keep format_national or format_international only if you need to display them directly to users.

How can I decide whether to send SMS or voice?
Use is_mobile and line_type. Only send SMS when is_mobile is true and line_type indicates a mobile number.

Can I schedule messages based on the user’s local time?
Yes. Use time_zones and utc_offset to schedule in local time. Persist these fields so you don’t need to revalidate on every send.

Where do I get an API key and how is billing handled?
Subscribe on the listing page to get your key. Billing is subscription + quota. Start with the 7-day trial when available on the listing.

Ship it

You can validate and normalize phone numbers today with a single GET call and one required parameter. Create your key, plug in the Authorization header, and standardize on E.164 in your data model. When you’re ready, start here: Start 7-day trial on Phone Validator API.