How to check if a phone number has been ported (MNP lookup explained step by step)

To check if a phone number has been ported, run an MNP lookup on it. The lookup compares the number with current portability and network data and returns three things: whether the number was ported, the code of the network that serves it now (MCC/MNC), and that network's country. The prefix alone can't tell you, because a ported number keeps its digits when it changes network.

This guide is the practical version: which method to use, how to read each field, how countries differ, and the exact API calls for one number or a whole list. For the background on why prefix-based carrier data goes wrong, see why carrier lookups can be wrong.

#What does "ported" mean?

A ported number is one that moved from one operator to another while the subscriber kept the same number. Mobile number portability (MNP) is a legal right in many countries. In the EU, the end-user has a right to keep their number when switching, "the receiving provider shall lead the switching and porting processes", and the number must be activated with the new provider "within one working day from the date agreed with the end-user" (Article 106, European Electronic Communications Code).

So every number has two networks worth knowing: the original network, which the number range was allocated to, and the current network, which actually serves the subscriber today. "Ported" means the two differ.

#Which methods can tell you if a number is ported?

Three kinds of lookup answer it, at different depths. A fourth, guessing from the prefix, can't.

If all you need is the network for routing, the MNP lookup is the right size of tool. If you also need to know whether the phone is switched on or the number is still assigned, the HLR lookup includes the porting answer, so there's no need to run both. The trade-offs are covered in HLR vs MNP vs number validation.

#Can a consumer check if a number is ported?

Sometimes, depending on the country, but mostly through tools meant for switching your own number, not for checking someone else's.

• United Kingdom. Customers text PAC to 65075 to get a switching code for their own number, and the new provider completes the switch within one working day (Ofcom). That starts a port; it doesn't look one up.
• India. A subscriber sends PORT followed by the ten-digit number to 1900 to get a Unique Porting Code, again for their own number (TRAI).
• Brazil. ABR Telecom, which administers number portability there, runs a public web form where you enter a number and see the operator that holds it now (ABR Telecom). It's a one-number, captcha-protected form, suitable for a single check by hand.

Short codes and web forms like these don't scale and aren't built for systems. For anything automated, or for numbers from many countries, use an API lookup.

#What do the fields in a porting result mean?

Each field answers one question. Read them together, and always with the time of the check.

MCC and MNC. The mobile country code and mobile network code come from ITU-T Recommendation E.212 (ITU). Together, for example 23410, they name one network. That makes mcc_mnc a stable key for routing tables, where operator brand names change with mergers and rebrands. Our guide to getting the MCC and MNC from a phone number shows how to map codes to operator names.

Original versus current network. The MNP lookup gives you the current network. The original network is the one the range was allocated to; the carrier lookup returns it as original_carrier, and only when it differs from carrier, so its presence is itself the porting signal. The MNP lookup doesn't return a porting date or a subscriber's identity. It describes where the number is routed, not who holds it.

#How does portability data differ by country?

The method of keeping track of ports varies, and so does how a lookup gets its answer. Three common patterns:

These are the patterns that affect how you check. Launch dates, porting times and published volumes for many more countries are in our mobile number portability atlas.

#Why does it matter whether a number is ported?

Because the current network decides how a message is routed, what it costs and whether it arrives.

• SMS routing and cost. Messaging routes and wholesale rates are often set per destination network. A text routed by the prefix to the old network may take a longer path, cost more, be rejected or arrive late. The current mcc_mnc fixes that. Our SMS routing use case walks through it.
• A2P termination. Business messages to a mobile network usually have to reach it through routes that network accepts. Knowing the real destination network lets you pick a route that terminates there, instead of finding out from failed delivery reports.
• Delivery reporting. If you group delivery rates by prefix, ported numbers land in the wrong operator's bucket and hide real problems. Group by current network.
• Fraud context. In a port-out scam, a criminal moves a victim's number to a network and SIM they control and then receives the victim's passcodes. In the US, the FCC adopted rules in 2023 requiring wireless providers to authenticate customers before moving their number and to notify them of port-out requests (FCC, 2023). A port on its own is normal; a change of network since you last checked, just before a password reset or payout, is a reason to step up. See SIM swap fraud signals for the full set of checks.

#How do I check if a number is ported, step by step?

Here is the whole flow with the MobileValidate API, from one number to a list.

1. Normalise the number. Use international E.164 format, for example +447700900006. National formats work only if you also send default_country.

2. Choose the check. mnp (alias porting, code number.mnp) answers the porting question. Use hlr instead if you also want live reachability.

3. Send it in real time. POST /v1/lookup takes up to 100 numbers and holds the request open for up to 30 seconds (wait, default 10). This request uses a test-mode number that always returns a ported answer:

curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"numbers": ["+447700900006"], "checks": ["mnp"]}'

4. Read the result. The documented test-mode answer for this number contains:

"number.mnp": {
  "service": "number.mnp",
  "status": "completed",
  "registered": true,
  "attributes": {"porting": "ported", "mcc_mnc": "23410", "country": "GB"},
  "checked_at": "2026-09-27T09:12:04.318Z",
  "cached": false,
  "billed": false
}

In live mode, billed is true for a conclusive answer. Other test numbers cover the remaining cases: +447700900001 returns not_ported, …003 returns unknown, …004 is pending first, and …005 returns unsupported_country (see the MNP lookup page).

5. Handle pending answers. If a network answers slowly, you get 202 with status: "pending" and a next.poll_url. Poll GET /v1/lookups/{id}?wait=30 until it completes. In a user-facing flow, don't block on it: use your default route and keep the answer for next time.

6. Store and compare. Save porting, mcc_mnc and checked_at with the record. On the next check, compare mcc_mnc with the stored value: a change means the number moved. Send max_age: 0 to force a fresh answer right before a sensitive account change.

#Should I check porting in real time or in bulk?

Use real time for decisions made one number at a time, and bulk jobs for lists.

A bulk job takes the same check in JSON or as an uploaded CSV:

curl https://api.mobilevalidate.com/v1/jobs \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -F file=@customers.csv -F checks=mnp

Run the same body through POST /v1/jobs/estimate first. It checks nothing, charges nothing, and returns the valid, invalid, duplicate and cached counts plus the maximum cost; pass that amount as max_cost and the job can never cost more. Unknown or inconclusive results are never charged. See bulk jobs for progress, results and downloads, and pricing for current prices.

#How should I act on each answer?

A simple decision table for routing and account security:

How often to refresh depends on the country and the use. Where ports complete within a day, a result from months ago is a hint, not evidence. Refresh stored networks before campaigns and after delivery failures, and use a fresh check before any action that relies on the number.

#What are the rules for using porting checks?

• Check only numbers you have a reason to process, such as customers, sign-ups and contacts who gave you their number. Porting data describes a person's phone number.
• No profiling. Don't use porting results for eligibility decisions such as credit, housing or employment. The lookup returns no name, SIM identifiers or location.
• No list building. Requests that look like sequential number ranges are refused (403 suspected_enumeration), and our acceptable use policy forbids finding recipients for unsolicited messages.
• Objections. People can object to checks of their number through our opt-out form; suppressed numbers are skipped and never charged.

Operator and regulator names are used descriptively. MobileValidate is not affiliated with any operator, regulator or portability administrator named here.

#What are the key takeaways?

• To check if a number is ported, run an MNP lookup: it returns ported / not_ported, the current network's mcc_mnc and its country.
• The prefix shows the original network only. Route and price by the current mcc_mnc.
• Use the HLR lookup when you also need live reachability; it includes the porting answer, so don't run both.
• Consumer short codes (UK PAC to 65075, India PORT to 1900) start a port of your own number; they don't look up others.
• Countries track ports differently and ports can complete within one working day, so store checked_at and refresh before decisions.
• A port is normal. A change of network since your last check is the signal worth acting on.
• Use real time for one-by-one decisions and bulk jobs for lists, with the free estimate first. Unknown answers are never charged.