Test the Phone Validator API from Zyla API Hub with Postman

You need to verify phone numbers before you send OTPs, SMS notifications, or enable user sign-up. By the end of this walkthrough, you’ll validate a phone number, inspect carrier/country/format metadata, and test everything in Postman using the Phone Validator API on Zyla API Hub.

What the Phone Validator API does

The Phone Validator API verifies whether a phone number is valid and returns rich metadata you can use to route, format, or block messages. The response includes validity flags, carrier/provider, country and ISO codes, national/international formats, time zones, line type (e.g., mobile), and more.

Illustration: Test the Phone Validator API from Zyla API Hub with Postman

Typical use cases:

Block invalid or disposable numbers before creating accounts.
Format numbers in E.164 or international style for consistent downstream processing.
Decide whether to send SMS vs. voice based on the line type.
Display geo-aware information (country, time zone) in admin tooling.

Like all services on Zyla API Hub, you use one account and one API key across the marketplace, with a subscription-and-quota model (not pay-per-call). For this API, the first plan offers a 7-day trial or 50 requests, and there is no Free Plan. Check the API page for current access options and pricing.

Getting started on Zyla API Hub

To try the Phone Validator API in minutes:

Open the API page: Phone Validator API.
Click Subscribe (or Start Free Trial when available). The first plan provides a 7-day trial or 50 requests; there is no Free Plan.
Copy your API key from your dashboard. All calls use the header Authorization: Bearer YOUR_API_KEY.

If you don’t have an account yet, you can Register to create one and get an API key.

Endpoint you’ll use

The Phone Validator API exposes this endpoint on Zyla API Hub:

Phone Validation
Method: GET
URL: https://zylalabs.com/api/10138/phone-validator-api/26579/phone-validation
Required query parameter:
- phone (string): Phone number to validate, e.g., +41799530236
Description: Validate phone numbers and retrieve carrier, country, line type, formatting, time zones, currency, international codes, and detailed metadata instantly.

Test it with Postman

1) Create a request

Set up a new GET request in Postman with the following:

Method: GET
URL: https://zylalabs.com/api/10138/phone-validator-api/26579/phone-validation?phone=%2B41799530236

2) Add authorization

Under Headers, add:

Authorization: Bearer YOUR_API_KEY

3) Send and inspect the response

Click Send. You should receive a JSON response with validity and metadata for the number.

Official cURL you can copy

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

Official example 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"
}

Field highlights you’ll likely use:

is_valid and is_possible: Gate account creation and message sending.
line_type and is_mobile: Route notifications via SMS or alternative channels.
format_e164 and format_international: Persist a canonical format in your DB and show a user-friendly version in admin UIs.
provider and country_iso2: Analytics and routing logic.
time_zones and utc_offset: Avoid sending messages at night in the recipient’s locale.

JavaScript example (Node.js)

This example calls the same endpoint and uses the fields you’ll commonly need to decide whether to proceed with an SMS:

import fetch from "node-fetch";

async function validatePhone(phone) {
const url = new URL("https://zylalabs.com/api/10138/phone-validator-api/26579/phone-validation");
url.searchParams.set("phone", phone);

const res = await fetch(url.toString(), {
method: "GET",
headers: {
"Authorization": "Bearer YOUR_API_KEY"
}
});

if (!res.ok) {
const text = await res.text();
throw new Error(`HTTP ${res.status}: ${text}`);
}

const data = await res.json();

// Minimal gating logic
if (!data.is_valid || !data.is_possible) {
return { ok: false, reason: "Invalid or impossible number", data };
}
if (data.line_type !== "mobile" || !data.is_mobile) {
return { ok: false, reason: "Non-mobile line; SMS may fail", data };
}

// Use canonical E.164 for storage and downstream systems
return {
ok: true,
e164: data.format_e164,
provider: data.provider,
country: data.country,
iso2: data.country_iso2,
timeZones: data.time_zones,
rfc3966: data.format_rfc3966,
data
};
}

validatePhone("+41799530236")
.then(result => console.log(JSON.stringify(result, null, 2)))
.catch(err => console.error(err));

Workflow patterns that ship

Signup gating: On user registration, call the endpoint. If !is_valid or !is_possible, block submission and prompt for correction.
Number normalization: Store format_e164 as the canonical value. Use format_international for operator-facing views and format_national for local display.
Messaging guardrails: Only enqueue SMS when is_mobile === true and line_type === "mobile". Optionally delay messages until local time_zones fall within business hours.
Routing and cost-awareness: Segment traffic by country_iso2, country_code, and provider for analytics or per-region sending strategies.

Implementation notes that save time

Authorization: Always include Authorization: Bearer YOUR_API_KEY in requests.
Idempotency: Validation is read-only; you can safely retry on transient network errors.
Caching: Since number metadata is relatively stable, cache positive validations keyed by format_e164 to reduce repeated lookups.
International formatting: Prefer format_e164 for programmatic usage. It removes spaces and hyphens and includes the leading “+”.
Time and locale: utc_offset is returned as a string (e.g., +02:00). Use time_zones for precise conversions.
Error handling: Treat non-2xx HTTP responses as operational failures; log response bodies to help diagnose quota or authorization issues.
Subscription model: Zyla uses subscription + quota, not pay-per-call. This API’s first plan offers a 7-day trial or 50 requests; there is no Free Plan. Monitor your usage in your Zyla dashboard.

Troubleshooting checklist

401/403? Confirm the Authorization header is present and the API key is valid.
4xx with message content? Check that the phone query parameter is supplied and URL-encoded.
Empty or unexpected fields? Validate with a different number to rule out edge cases. Persist format_e164 and re-run.
App-specific issues? Log the raw JSON response for quick diffing against local parsing code.

Call the API from AI agents via MCP

Every API on Zyla can be called from MCP-compatible tools like Claude Code, Cursor, and Windsurf. Point your agent or client to the MCP endpoint and pass your API key in the query string:

https://mcp.zylalabs.com/mcp?apikey=YOUR_API_KEY

From there, your agent can invoke the same Phone Validation endpoint using the marketplace routing. For integration specifics and client setup, see the MCP docs. This is useful when you want an AI assistant to validate numbers inline during code generation or test runs.

End-to-end Postman recipe you can reuse

Request setup

New Request → GET
URL: https://zylalabs.com/api/10138/phone-validator-api/26579/phone-validation?phone=%2B41799530236
Headers: Authorization: Bearer YOUR_API_KEY
Send

Quick test scripts (optional)

If you use Postman tests, you can add quick assertions like:

pm.test("HTTP 200", function () {
pm.response.to.have.status(200);
});
const body = pm.response.json();
pm.test("Valid mobile number", function () {
pm.expect(body.is_valid).to.eql(true);
pm.expect(body.is_mobile).to.eql(true);
});

Why use Zyla API Hub for this integration

One account, one API key, one subscription model across more than 10,000 public APIs on the hub.
Centralized billing with subscription + quota (not pay-per-call), and dashboards to monitor usage.
Consistent auth across endpoints: Authorization header with your key.

Explore additional services on Zyla API Hub when you’re ready to expand this workflow (e.g., messaging, enrichment, or fraud tooling) without switching auth models.

FAQ

What’s the exact endpoint for validation?
Use GET https://zylalabs.com/api/10138/phone-validator-api/26579/phone-validation with the phone query parameter.

How do I authenticate?
Pass your key in the header: Authorization: Bearer YOUR_API_KEY.

Is there a free plan?
No. The first plan provides a 7-day trial or 50 requests. Check the API page for current access options and pricing.

Which fields should I store?
Persist format_e164 as the canonical number. Store is_valid, is_possible, line_type, country_iso2, and provider if they’re relevant to your routing or analytics.

Can I call this from an AI agent?
Yes, via the MCP endpoint at https://mcp.zylalabs.com/mcp?apikey=YOUR_API_KEY. See the MCP docs for client specifics.

Ready to test the Phone Validator API in your stack? Open the Phone Validator API page, subscribe, and start calling it from Postman or code. If you need an account, Register to get your API key and ship your integration this week.