Messaging-app registration checks: a guide for every app

A messaging-app registration check tells you whether a phone number you hold can be associated with an account on an app such as WhatsApp, Telegram, Viber, Signal, LINE or Zalo, or whether it can receive iMessage or RCS. Each answer is registered, not registered or unknown, with the time of the check. Nothing is sent to the number. This guide covers all twelve messaging checks we offer: which ones run in real time and which in bulk only, what a "no" means on each app, why answers come back unknown, how billing works, and how to use them with consent.

#What does a registration check answer, and what doesn't it?

It answers one narrow question per app: can an account on this platform be found through this phone number right now? That supports three jobs:

• Channel selection for messages people already expect, such as passcodes, delivery updates and reminders. See channel selection.
• Deliverability. A number with a messenger account passed that app's own phone verification at some point, so it's less likely to be a typo or an invented entry.
• Risk signals at sign-up, as one input among several.

It doesn't answer who owns the number, whether they read messages, whether the phone is switched on, or whether you may contact them. We never return names, photos, usernames, profile links or last-seen times. Every conclusive answer carries checked_at, because accounts come and go and carriers reassign numbers. An answer from this morning is stronger than one from last quarter.

#Which apps can be checked, and in which mode?

This table covers every messaging check in our services reference. Prices change, so see current per-check prices for real-time and bulk on the pricing page.

You're not charged for inconclusive results (unknown, unsupported country, timeout, invalid, duplicate). All twelve checks accept numbers from every country.

#Why are some checks real time and others bulk only?

Real-time checks answer inside the request, usually within seconds, which suits sign-up forms and the moment before you send a passcode. Bulk-only checks gather answers in batches, so they run in bulk jobs: you submit up to 50,000 numbers and e-mails, follow progress, then download the results.

If you send a bulk-only check to the real-time endpoint, it's refused before anything is checked. This is the real test-mode response for POST /v1/lookup with checks: ["imessage"]:

{"error": {"code": "service_disabled",
  "message": "The check 'imessage.registered' is available in bulk jobs only (POST /v1/jobs).",
  "status": 403, "retryable": false, "param": "checks[0]"}}

The practical rule: use real-time checks at the moment of contact, and run bulk-only checks ahead of time over your opted-in base, for example once a month. Store the answers with their dates and route from your own records. GET /v1/services returns a modes array for each service, so your code never has to hard-code which is which.

#What does a "not registered" answer mean on each app?

A conclusive false is not equally strong everywhere. On apps where the phone number is the account, it's informative. On apps where people can hide from number search, it often means "not findable through this number".

Never treat false alone as proof that a number is fake. Combine it with line type and your own signals.

#Why do checks come back unknown?

Unknown (registered: null) means no conclusive answer was obtained. The status and reason fields say why:

Two rules keep your data clean. Unknown is never a no: don't route, score or delete on it. And never overwrite a stored conclusive answer with unknown. A timeout today doesn't erase what you learned last month.

#What does a real request look like?

A real-time lookup can check several apps at once. This is real test-mode output for three test numbers with checks: ["whatsapp", "telegram", "viber", "zalo"], trimmed to the answers:

curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"numbers": ["+447700900001", "+447700900002", "+447700900003"],
       "checks": ["whatsapp", "telegram", "viber", "zalo"], "wait": 5}'

"+447700900001": {"whatsapp.registered": true,  "telegram.registered": true,  "viber.registered": true,  "zalo.registered": true}
"+447700900002": {"whatsapp.registered": false, "telegram.registered": false, "viber.registered": false, "zalo.registered": false}
"+447700900003": all four "status": "unknown", "registered": null, "reason": "UPSTREAM_TIMEOUT"

For bulk-only apps, the same numbers go into POST /v1/jobs. A real test job for the same three numbers with ["line", "zalo", "botim", "max"] completed at once with "progress": {"total": 3, "checks_total": 12, "done": 12, "conclusive": 8}. Test keys are free and never bill, and test answers are invented.

#How do I route checks to real-time lookups and bulk jobs automatically?

Read the catalog once, then send each check where it can run. This Python sketch uses modes from GET /v1/services:

import os, requests

API = "https://api.mobilevalidate.com"
H = {"Authorization": f"Bearer {os.environ['MOBILEVALIDATE_API_KEY']}"}

services = requests.get(f"{API}/v1/services", headers=H, timeout=20).json()["data"]
realtime = {s["code"] for s in services if "realtime" in s["modes"]}
ALIASES = {"whatsapp": "whatsapp.registered", "telegram": "telegram.registered",
           "imessage": "imessage.registered", "rcs": "rcs.registered", "line": "line.registered"}

def split_checks(checks):
    rt = [c for c in checks if ALIASES.get(c, c) in realtime]
    bulk = [c for c in checks if ALIASES.get(c, c) not in realtime]
    return rt, bulk

rt, bulk = split_checks(["whatsapp", "telegram", "imessage", "rcs", "line"])
# rt   → POST /v1/lookup at sign-up (up to 100 numbers per request)
# bulk → POST /v1/jobs nightly or monthly over consented customers (up to 50,000 per job)
print(rt, bulk)   # ['whatsapp', 'telegram'] ['imessage', 'rcs', 'line']

Limits to plan around: 20 checks per request, 2,000 number × check pairs per lookup and 100,000 per job. Call the free POST /v1/jobs/estimate first to see the maximum cost of a job.

#How often do registration results change?

It depends on the app. Established messengers where the number is the account change slowly: people keep the same WhatsApp or Viber account for years, until they change number. Some things change faster:

• RCS capability depends on the carrier, the handset and a setting. Google's RCS documentation notes that a device must have connected to the RCS service within the last 31 days to be reported as capable (Google, 2026).
• New apps such as MAX gain users quickly, so answers for the same number can flip.
• Recycled numbers. When a carrier reassigns a number, the old account may linger or disappear.

A practical cadence: refresh messenger checks monthly and after any failed delivery. Use a shorter max_age for RCS. Repeat checks inside the freshness window are served from your account's cache for free (cached: true, billed: false), and max_age: 0 forces a fresh, billed check.

#How do I pick which apps to check in each country?

Check the channels you could actually send on, and weight them by where your customers live. Published scale figures are few, and they're self-reported: WhatsApp reported two billion users in 2020, Telegram's FAQ says it has over one billion active users, and LY Corporation reports that LINE had about 100 million monthly active users in Japan at the end of March 2026.

Then measure registration rates on your own consented base, as our channel-by-country guide shows. Your data beats any country table.

#Is it legal, and how do I use the checks responsibly?

The number usually belongs to a person, so a check is likely to be processing of personal data. This is general guidance, not legal advice (consult counsel about your own situation), but three rules cover most situations:

1. Check only numbers you hold for a legitimate reason: customers, sign-ups and leads who gave you their number. Under the GDPR you need a lawful basis (Article 6), and data minimisation (Article 5(1)(c)) suggests storing only the answer and its date.
2. Registration is not consent. The WhatsApp Business Messaging Policy allows businesses to contact only people who gave their number and opted in. Other platforms have similar rules.
3. No list building. Researchers showed in 2021 that contact discovery can be abused to map who uses an app at scale (NDSS 2021). So the API refuses 20 or more consecutive numbers (403 suspected_enumeration), applies a daily cap per account, and our acceptable use policy forbids finding recipients for unsolicited messages.

People can object through our opt-out form; suppressed numbers are skipped and never charged. Platform names are used descriptively only. MobileValidate is not affiliated with any of the platforms named here.

#What are the key takeaways?

• A registration check returns registered, not registered or unknown with checked_at, and nothing else: no names, profiles or activity.
• WhatsApp, WhatsApp Business, Telegram, Viber and Zalo run in real time. Signal, iMessage, RCS, LINE, Botim, MAX and Messenger run in bulk jobs only.
• A false is strong where the number is the account (WhatsApp, Viber) and weak where people can hide from number search (Telegram, Signal, Messenger).
• Unknown is missing data. It's free, and it should never overwrite a stored answer.
• Refresh monthly, faster for RCS and new apps, and use the cache to keep repeat checks free.
• Check only numbers you hold, for messages people expect. Start with the test numbers and the app guides for WhatsApp, Telegram, iMessage and RCS.