NexCheck-筛号平台
When you have a list of mobile numbers and need to know which are usable and which have accounts on target platforms, you typically go through three levels of treatment: format standardization and deduplication, basic telecom status verification, and platform account status detection. This order cannot be reversed—the later steps depend on the quality of the earlier data. Submitting without proper formatting will directly impact match rates and waste detection costs.
Step 1: Standardize the List to E.164 Format
The international standard for telephone numbers is ITU-T E.164. The structure is +国家代码 + 国内有效号码, with a maximum length of 15 digits, no parentheses, hyphens, spaces, or domestic trunk prefixes. For example, a UK number like 07xxx becomes +447xxx in E.164, without the leading zero.
Common issues in lists: an extra zero before the area code, prefixes written as 00 or 011, parentheses or hyphens, and mixed international numbers without country separation. These need to be cleaned before submitting for detection; otherwise, the system will not recognize them during number matching.
For mixed international lists, it is best to first separate by country code and then standardize each group. Different countries have different number rules, and uniform processing can lead to errors. Deduplication should also be done at this stage: submitting the exact same E.164 number multiple times is pointless—just remove duplicates.
For specific formatting rules, refer to: How to Normalize E.164 Before Screening International Numbers? 4 Types of Dirty Number Rewriting Rules
Step 2: Basic Telecom Status Verification
After formatting is unified, run basic verification first to exclude clearly invalid numbers. There are two methods, each with a different purpose:
Carrier / Line Type Lookup: Extracts line type (mobile, landline, VoIP) and carrier information from number planning databases and number portability records. This does not query the network in real time, so it is fast and low-cost. It is mainly used to filter out landlines and VoIP numbers—if your target platform only supports mobile numbers, this step can remove non-mobile numbers early.
HLR Lookup: Confirms the current status of a number in real time via mobile core network signaling. It can distinguish between active, powered off, suspended, and nonexistent numbers. It is more accurate than carrier lookup because it checks real-time status rather than number planning records, but the cost per lookup is higher.
A common funnel order is: first use carrier lookup to filter out landlines and VoIP, then run HLR lookup on the remaining mobile numbers to confirm network status. Note that this step only indicates whether the number is valid on the carrier side; it does not indicate whether the number has an account on a specific application.
Step 3: Platform Account Status Detection
Being active on the carrier network does not mean the number is registered on WhatsApp, Telegram, or other platforms; and having an account does not mean it is currently active or not banned. These two dimensions come from different sources and cannot substitute for each other.
The fields returned by platform-level detection vary by platform. Common ones include: whether an account is open, registration time, account activity status, and whether it is banned. Some platforms also return demographic attributes such as gender and age. The detection items available vary by platform and may change with platform policies. Check what is currently supported in practice.
If you have an existing list of numbers and need to know which ones have accounts on target platforms, NexCheck supports bulk detection of number status by platform, returning results grouped by valid and invalid. The current detection fields supported by each platform can be viewed on the platform page.
How to Store Results
After detection, how you handle the results depends on the nature of the list:
Static bulk lists (e.g., existing customer tables exported from CRM): Upload CSV or TXT, run the process, then export by group and write back to the source database. Before upload, ensure the encoding is UTF-8, numbers are in a single column, and in E.164 format.
Dynamic incoming leads (e.g., form registrations, real-time lead acquisition): Integrate via REST API, use Webhook async callbacks to write detection results back to CRM or user database in real time, and automatically route new leads as they come in—no manual operation needed.
Regardless of the method, results should be stored in multiple fields rather than keeping only a single "valid/invalid" flag. Fields like line type, registration time, and activity status may be needed later; if you drop them, you will have to rerun the process.
For guidance on designing the database structure for result fields, refer to: Don't Just Look at Valid/Invalid in Bulk Number Verification—Store Results in Multiple Columns
Comments(0)