# Messaging-app registration checks: a guide for every app > What a registration check tells you for WhatsApp, Telegram, Viber, Signal, iMessage, RCS, LINE, Zalo and more: modes, unknowns, billing and consent. Canonical: https://mobilevalidate.com/blog/messaging-app-registration-checks-guide · Last updated: 2026-09-25 ![Cover: Messaging-app registration checks: a guide for every app](https://mobilevalidate.com/og/blog/messaging-app-registration-checks-guide.png) By MobileValidate team (https://mobilevalidate.com/about) · Published: 2026-09-25 · Category: Guides · Tags: Channel selection, Messaging, WhatsApp, iMessage, RCS, Consent 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](/use-cases/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](/docs/services). Prices change, so see current per-check prices for real-time and bulk on the [pricing page](/pricing). | App | Check (alias) | Mode | What `true` means | |---|---|---|---| | WhatsApp | `whatsapp` | real time + bulk | An account exists for the number | | WhatsApp Business | `whatsapp.business` | real time + bulk | Account exists; `business` flag says if it's a business account | | Telegram | `telegram` | real time + bulk | An account can be found by the number | | Viber | `viber` | real time + bulk | An account exists for the number | | Zalo | `zalo` | real time + bulk | An account exists for the number | | Signal | `signal` | bulk only | A discoverable account exists | | iMessage | `imessage` | bulk only | Registered for iMessage on an Apple device | | RCS | `rcs` | bulk only | The number could receive RCS at check time; may add `device_os` | | LINE | `line` | bulk only | An account is associated with the number | | Botim | `botim` | bulk only | An account exists for the number | | MAX | `max` | bulk only | An account exists for the number | | Messenger | `messenger` | bulk only | A Messenger account is linked to the number | 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](/docs/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"]`: ```json {"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". | App | How strong is `false`? | Why | |---|---|---| | WhatsApp, Viber, Zalo | Strong | The number is the account. Zalo users can limit who finds them by number, so a small share may not be confirmable | | Telegram | Weak | By default a number is visible only to the person's contacts, and people control whether they can be found by number ([Telegram FAQ](https://telegram.org/faq)) | | Signal | Weak | Since 2024 people can set "Who can find me by my number" to Nobody; then others can't "even know that you have a Signal account" ([Signal, 2024](https://signal.org/blog/phone-number-privacy-usernames/)) | | LINE | Medium | People also connect by LINE ID and QR code, and not every account is findable by number | | Messenger | Weak | A phone number is optional on the account | | iMessage | Medium | `false` is normal for Android users; see our [iMessage guide](/blog/check-if-a-number-has-imessage) | | RCS | Medium, and short-lived | Depends on carrier, handset and settings; see the [RCS guide](/blog/rcs-capability-check-explained) | 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: | `status` / `reason` | Typical cause | What to do | |---|---|---| | `unknown` / `UPSTREAM_TIMEOUT` | The answer didn't arrive in time | Keep your default channel; try again later | | `unsupported_country` | The service doesn't cover the number's country | Use another channel for that country | | `pending` | Still being checked when `wait` ran out | Poll `GET /v1/lookups/{id}` or use a [webhook](/docs/webhooks) | | `number_status: invalid_number` or `duplicate` | The number was never checked | Fix the record or drop the duplicate | 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](/docs/test-mode) with `checks: ["whatsapp", "telegram", "viber", "zalo"]`, trimmed to the answers: ```bash 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}' ``` ```json "+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`: ```python 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](https://developers.google.com/business-communications/rcs-business-messaging/guides/build/capabilities)). - **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](https://blog.whatsapp.com/two-billion-users-connecting-the-world-privately), Telegram's [FAQ](https://telegram.org/faq) says it has over one billion active users, and LY Corporation reports that LINE had about [100 million monthly active users in Japan](https://www.lycbiz.com/jp/service/line-official-account/) at the end of March 2026. | Customer base | Checks worth running | |---|---| | Global consumer app | `whatsapp`, `telegram`, plus `rcs` and `imessage` in bulk for format planning | | Japan, Taiwan, Thailand | `line` (bulk), `whatsapp` | | Vietnam | `zalo`, `whatsapp` | | Eastern Europe, Balkans | `viber`, `whatsapp`, `telegram` | | UAE | `whatsapp`, `botim` (bulk) | | Russia | `telegram`, `whatsapp`, `max` (bulk) | Then measure registration rates on your own consented base, as our [channel-by-country guide](/blog/choosing-a-messaging-channel-by-country) 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](https://eur-lex.europa.eu/eli/reg/2016/679/oj) 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](https://business.whatsapp.com/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](https://eprint.iacr.org/2020/1119)). So the API refuses 20 or more consecutive numbers (`403 suspected_enumeration`), applies a daily cap per account, and our [acceptable use policy](/legal/acceptable-use) forbids finding recipients for unsolicited messages. People can object through our [opt-out form](/opt-out); 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](/docs/test-mode) and the app guides for [WhatsApp](/blog/check-if-a-number-is-on-whatsapp-api-guide), [Telegram](/blog/telegram-number-check-guide), [iMessage](/blog/check-if-a-number-has-imessage) and [RCS](/blog/rcs-capability-check-explained). ## Sources 1. [Two Billion Users: Connecting the World Privately](https://blog.whatsapp.com/two-billion-users-connecting-the-world-privately) — WhatsApp, 2020 2. [Telegram FAQ](https://telegram.org/faq) — Telegram, 2026 3. [Keep your phone number private with Signal usernames](https://signal.org/blog/phone-number-privacy-usernames/) — Signal, 2024 4. [What is the difference between iMessage, RCS, and SMS/MMS?](https://support.apple.com/en-us/104972) — Apple, 2026 5. [Capability checks (RCS for Business)](https://developers.google.com/business-communications/rcs-business-messaging/guides/build/capabilities) — Google for Developers, 2026 6. [LINE Official Account (LINE monthly active users in Japan)](https://www.lycbiz.com/jp/service/line-official-account/) — LY Corporation, 2026 7. [All the Numbers are US: Large-scale Abuse of Contact Discovery in Mobile Messengers (NDSS 2021)](https://eprint.iacr.org/2020/1119) — IACR ePrint / NDSS, 2021 8. [WhatsApp Business Messaging Policy](https://business.whatsapp.com/policy) — WhatsApp, 2026 9. [General Data Protection Regulation (EU) 2016/679](https://eur-lex.europa.eu/eli/reg/2016/679/oj) — European Union, 2016 ## Frequently asked questions ### Which messaging-app checks run in real time? WhatsApp, WhatsApp Business, Telegram, Viber and Zalo run in real time on POST /v1/lookup and in bulk jobs. Signal, iMessage, RCS, LINE, Botim, MAX and Messenger run in bulk jobs only. ### What does unknown mean in a registration check? It means no conclusive answer was obtained, for example because of a timeout, an unsupported country or a temporary service problem. It is not a no. registered is null, a reason is given, and the check is not charged. ### Does a registered answer mean I can message the person on that app? No. It means an account can be associated with the number. You still need the person's consent for that channel, and each platform has its own business-messaging rules. ### Is anything sent to the number when it is checked? No. Nothing is sent to the number and no name, photo, username or profile is returned. The answer is registered, not registered or unknown, with the time of the check. ### How often should I re-check registration? Monthly is enough for most messenger checks, plus a re-check after a failed delivery. RCS capability and newer apps change faster, so use a shorter max_age for them.