ForHosting KIT · Validation

Look up a phone carrier

Identifying who operates a phone number, and whether it's mobile, landline or VoIP, is a useful signal — but it isn't something the digits reveal on their own, and it isn't what this endpoint returns.

● BetaPer request + per item$0.002

Run — $0.002 How it works & API

Use it from WebAPIEmailTelegramApp soon

Run it online

Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.

Accurate carrier and line-type detection requires a query to a licensed HLR (Home Location Register), the per-network database that tracks where a number currently lives. That HLR lookup is not wired here: this endpoint does not return a carrier name, a line type or a country. For the phone checks that do work today, use format validation.

Why the digits don't reveal the carrier

For years, the first digits of a phone number mapped to a single operator, and a lookup table was enough. Number portability ended that: subscribers keep their number when they switch networks, so a prefix no longer tells you the current carrier. The only authoritative source is the operator's HLR — a licensed, per-network database — which is exactly why accurate carrier and line-type detection is a licensed service rather than something you can derive from the number alone. Guessing from a stale prefix table produces confident, wrong answers.

What this endpoint returns today

This endpoint does not currently perform an HLR lookup. It does not return a carrier or operator name, a line type (mobile, landline or VoIP), or a country. Wiring live carrier detection requires a licensed HLR provider, which is not connected here, so if your integration depends on carrier or line-type data, this endpoint will not supply it. We would rather say that plainly than return a guessed carrier that your routing or fraud logic would then trust.

What is available: phone format validation

What works today is validating a phone number's format: confirming it has a plausible structure and length for its country code, catching a transposed digit or a number that is simply too short before you rely on it. That is a separate, working capability — it will not tell you the carrier or line type, but it stops malformed numbers at the door, and it is the right first step before any number goes to a licensed carrier service.

Why line type matters — and why it needs a licensed source

The reason teams want this data is real: a landline cannot receive an SMS, and a VoIP number is cheap to provision and easy to discard, which is why fraud teams watch for it. But precisely because that data drives routing and risk decisions, it has to come from an authoritative HLR feed rather than a heuristic. Approximating it would trade a wrong SMS for a wrong fraud score — worse than no answer at all, because a wrong answer is one your systems act on with confidence.

If you need carrier data

If your use case genuinely requires carrier or line-type routing, it needs a licensed HLR feed, which is a capability decision rather than something this endpoint approximates. In the meantime, validate number format so that only well-formed numbers reach whatever carrier service you use, and treat carrier and line-type detection as a distinct step you source from a licensed provider. Access to the KIT runs on prepaid balance, and a failed task is never charged.

What you can do with it

Catch malformed numbers at signup

Validate a phone number's format at signup to reject a transposed or too-short number before it is saved, using phone format validation rather than a carrier lookup.

Clean a contact list

Screen a stored contact list for numbers that are not structurally valid for their country code, so a later campaign is not built on broken data.

Prep numbers for a licensed carrier lookup

Validate format first so only well-formed numbers are sent on to a licensed HLR carrier service, avoiding wasted queries on malformed input.

Avoid gating SMS on a carrier guess

Because line type is not returned here, do not decide SMS-versus-voice from a guessed carrier; validate the format and confirm reachability through your SMS provider's delivery result instead.

FAQ

What does this endpoint return?

It does not return a carrier name, a line type or a country, and it does not perform an HLR lookup. For a working phone check, use format validation, which confirms a number is structurally plausible for its country.

Can it tell me if a number is mobile or landline?

No. Line-type detection — mobile, landline or VoIP — requires a query to a licensed HLR, which this endpoint does not perform.

Is it free to use?

There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.

Should I use this or phone format validation?

For anything you can act on today — catching malformed numbers — use format validation. This carrier endpoint does not return carrier or line-type data, so it cannot drive routing or fraud decisions on its own.

Why doesn't it just estimate the carrier from the number?

Because number portability makes a prefix an unreliable guess — a subscriber keeps their number across operators. A wrong carrier is worse than no carrier for routing and fraud logic, so this endpoint does not approximate one.

Do I need to validate the number first?

Yes. Run phone format validation to confirm the number is structurally correct — that's the working check. Carrier and line-type detail would come from a separate licensed HLR service.

How do I receive the result?

You get a task_id immediately, and the response arrives via your signed webhook or a signed link valid for 24 hours, consistent with how every task on this API resolves.

Is the submitted number kept?

No. The submitted number and its result are deleted once the retention window closes and are never used for training.

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/verify/phone-carrier

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/verify/phone-carrier \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"phone":"+34600123456"}'

const res = await fetch("https://api.kit.forhosting.com/verify/phone-carrier", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "phone": "+34600123456"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/verify/phone-carrier",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "phone": "+34600123456"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/verify/phone-carrier", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"phone":"+34600123456"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"phone":"+34600123456"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/verify/phone-carrier", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "phone": "+34600123456"
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "verify.phone_carrier",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.

Read the full KIT documentation →