NexCheck-筛号平台
You've just finished a round of number screening, and the results table is written, but you're wondering: how long can you trust these conclusions? Can you use them directly tomorrow for sending messages? Let's get to the point: bulk screening results have no platform-defined "validity period in days." Whether results are invalid depends on three observable signals: whether the probing side hit rate limits, whether the list side changed, and whether the outreach side shows discrepancies.
Most screening APIs in the industry (like CheckNumber.AI, etc.) provide a force_check cache switch by default, meaning cache reads are the engineering default, and the only question is when to force a refresh. Let's break down the three signal tiers below.
Conclusion First: Bulk Screening Results Expire Based on Three Signals, Not Fixed Days
Don't assign a "30-day expiry" on your calendar to results. Instead, monitor these three types of signals, and trigger a re-check whenever they appear.
| Signal Side | Observable Metric | Re-check Trigger Condition | Priority |
|---|---|---|---|
| Probing Side | 429 responses, retry_after field, consecutive timeouts | If rate limiting was hit during detection, results may be mixed with anomalies | High |
| List Side | New imports, field edits, normalization version changes | Number key values change, old conclusions are incomparable | Medium |
| Outreach Side | Send failure rate diverges from detection conclusion | Failures concentrate in a specific batch or time window | High |
These three signal types cover the vast majority of result invalidation scenarios, more reliable than fixed days.
Signal One (Probing Side): Conclusions Obtained Within Rate-Limiting Windows Should Not Go Directly into the Main Table
Why pay attention to the probing side? Because detection results are produced under rate-limiting pressure. LINE Messaging API sets per-endpoint rate limits per second; exceeding them returns a 429 error (LINE official spec updated May 2026), requiring client-side rate control and exponential backoff. Telegram requires at least 3-second debouncing for contacts.resolvePhone to avoid flood wait. If probing is forced within a rate-limiting window, the conclusions are low-confidence, especially for batches returning 429 or retry_after.
Practice: Mark results returned during 429 or retry_after periods as "anomalous unknown" rather than negative conclusions, and queue them separately for re-check.
Signal Two (List Side): New Imports, Number Rewrites, and Re-normalization Make Old Conclusions Incomparable
The list itself changed, so old conclusions are invalid. Three common cases:
- New batch imports mixed with the old list;
- CRM number fields manually edited (e.g., adding country codes);
- E.164 normalization rule changes causing the same number's key value to change.
Practice: Use the normalized number as the cache primary key, record the normalization version, and treat key value changes as new numbers requiring forced re-probing. If you're using a bulk number detection API provided by the platform, you can include the version number when submitting for later filtering by version.
Signal Three (Outreach Side): When Send Failure Rate Diverges from Detection Conclusion, Which Part to Re-check First
The troubleshooting order for "detection shows available but sending still fails" is important. First distinguish four concepts: format validity, platform registration, account activity, and reachability; they are progressively layered. For example, Telegram's PHONE_NOT_OCCUPIED could mean either unregistered or user privacy settings blocking, not necessarily "no account."
Troubleshooting steps:
- Look at which platform and batch the failures concentrate in;
- If failures concentrate in a certain time window, it's likely detection hit rate limiting then, prioritize re-checking that window's subset;
- Check if it's due to high sending frequency triggering platform risk control, rather than the number itself.
You can refer to the multi-platform number detection approach for cross-platform status matrix comparison.
Why the "Unknown" Tier Must Be Re-checked on a Separate Schedule, While "Registered" Doesn't Need Re-running Every Round
Model detection results as three tiers, not simple booleans:
| Tier | Meaning | Re-check Priority |
|---|---|---|
| Registered | Account explicitly detected | Low, changes slowly, can extend reuse |
| Not Found | Unregistered or privacy limits, like PHONE_NOT_OCCUPIED | Medium, depends on use case |
| Anomalous Unknown | Rate limit or timeout during probing, result unclear | High, lowest information, most worth re-running |
If you compress three tiers into a boolean, you lose information, leading to false negatives. So the results table should keep a tier status column.
How to Use the Cache Switch: When to Read Cache vs. When to force_check
The force_check parameter is a cache switch provided by most screening APIs; it defaults to reading cache to save quota and reduce rate-limiting risk. Only force re-probing when the three signals above occur.
Re-check cadence by list type (experience values, not platform rules):
| List Type | Suggested Cadence |
|---|---|
| High-frequency outreach list (active in last 7 days) | Random sample subset every 2-3 days |
| Quarterly dormant list | Full re-check every quarter |
| One-time campaign list | Re-check once before campaign |
Re-check Only Subsets: Batch ID, Detection Timestamp, and Incremental Task Queue
In implementation, the results table should retain batch ID, normalization version, detection timestamp, status tier, and error code columns. Use query conditions to filter the subset to re-check, hand it to an async queue for batched submission, and use callbacks to write back status, avoiding full re-runs.
Specific fields:
| Field | Purpose |
|---|---|
| batch_id | Distinguish source batch |
| normalized_version | Normalization version |
| checked_at | Detection timestamp |
| status_tier | Registered/Not Found/Anomalous Unknown |
| error_code | 429, timeout, etc. |
For example: first filter subsets like status_tier='异常未知' AND error_code='429', then re-check and write back.
This is where NexCheck comes in: it offers a web-based bulk filter and RESTful API for batch submission, real-time query, and webhook callbacks, allowing you to make re-checks incremental tasks driven by batch ID and detection timestamp, with callbacks writing back status columns, rather than full re-runs each round; it also supports WhatsApp number bulk detection, social account registration detection, and other multi-platform unified submission, reducing the cost of maintaining separate caches and retry strategies per platform.
Re-check Cost Accounting: How to Estimate Duplicate Submissions, Concurrency Limits, and Quota
Re-checking isn't free; estimate costs:
- Calculate the actual re-run volume per round by tier proportion, e.g., if anomalous unknown is 5%, only re-run that part;
- Include retries due to rate-limit backoff in quota consumption, as each retry may consume quota;
- Set a stop-loss rule: max 2 re-probes per number per cycle to prevent infinite loops.
This controls costs without wasting resources.
FAQ
How long are screening results valid?
There is no platform-defined "validity period in days;" no fixed number. Whether results are valid depends on three signals: whether rate limits were hit during probing, whether the list changed, and whether outreach failure rates are abnormal. If all three are normal, continue reusing cache; if anomalies appear, re-check even if just completed.
How often should bulk screening be re-run?
No uniform interval; adjust by list type. High-frequency outreach lists: random sample subset every 2-3 days; quarterly dormant lists: full re-check every quarter; one-time campaign lists: re-check once before campaign. These are operational experience values, not official rules.
What does the force_check parameter mean?
force_check is the cache switch for screening APIs; it defaults to reading cache to save quota, and when set to true, forces bypassing cache to re-probe. Applicable scenarios: suspected number changes, last probe hit rate limiting, or outreach failures despite detection showing normal; force refresh a single or subset.
Do previously screened numbers need to be re-screened?
Not necessarily. If the list hasn't changed, no rate limits were hit last time, and outreach is normal, you can read cache directly; if new imports, number rewrites, or failure rate increases occur, re-probe the affected subset. Prioritize re-running the "anomalous unknown" tier, no need for full re-runs.
Does PHONE_NOT_OCCUPIED mean unregistered or privacy-blocked?
Both are possible. Telegram's official documentation (updated May 2026) states this return code can be either the number not being registered or the user setting privacy to prevent phone number lookup. You can't conclude "no account" from this alone; mark it as "Not Found" tier and combine with other channel information for comprehensive judgment.
How to troubleshoot when detection shows available but sending fails?
First distinguish the four layers: format validity, platform registration, account activity, reachability. Then check if failures concentrate in a specific batch or time window. If concentrated in a certain period, it's likely detection hit rate limiting then, prioritize re-checking that subset; if sending fails in one direction only, it may be platform risk control, so check sending frequency.
Comments(0)