Article summary
Facebook and Messenger Registration Checks both return phone and registration status, but their platform signals, CRM fields, and use cases must remain separate.
Facebook and Messenger number checking are not one result with two labels. AppShai currently accepts TXT phone input for both Registration Check tasks and exports Phone plus Registration Status to Excel. The services target different platform boundaries, so results belong in separate CRM fields.
Neither task reads private messages or returns friend relationships, reply probability, activity time, interests, or marketing permission. A positive signal for one platform does not establish the other.
Direct answer: use Facebook Registration Check for a Facebook signal and Messenger Registration Check for a Messenger signal. Run, store, and timestamp them separately.
Facebook vs Messenger Registration Check
| Dimension | Messenger | |
|---|---|---|
| Input | TXT, one phone per line | TXT, one phone per line |
| Export | Excel | Excel |
| Service fields | Phone, Registration Status | Phone, Registration Status |
| Meaning | Signal returned by Facebook task | Signal returned by Messenger task |
| CRM field | facebook_registration | messenger_registration |
| Not returned | Chats, activity, identity, permission | Chats, activity, identity, permission |
Why identical schemas still require separate fields
A similar schema does not make two platform facts interchangeable. Email Verified and Phone Verified may both be yes/no, but they are still independent evidence.
| Mistake | Problem | Correct model |
|---|---|---|
| Merge into social_registered | Loses provenance | Keep two platform fields |
| Copy yes from one to the other | Creates a false fact | Unknown remains unknown |
| Overwrite all dates with the latest task | Destroys recency | Separate checked_at fields |
| Write result into permission | Confuses state and authorization | Independent permission |
| Infer activity from registration | Exceeds the field contract | Interpret literally |
Select the task by business question
| Question | Task | Additional evidence |
|---|---|---|
| Did this list return Facebook signals? | Facebook Registration | Country evidence and task date |
| Did it return Messenger signals? | Messenger Registration | Country evidence and task date |
| Which channel does the customer prefer? | Neither alone | Form choice and interaction |
| Where may we contact the person? | Checking cannot decide | Channel permission and purpose |
| Can private chats be read? | Outside the service | Lawful first-party conversation system |
Correct dual-platform workflow
- Select phones with traceable provenance and a defined inventory need.
- Preserve phone_raw and contact_id; normalize from country evidence.
- Create UTF-8 TXT with one phone per line.
- Run Registration Check separately in the Facebook Number Checker and Messenger Number Checker.
- Export two Excel files and retain their task IDs and dates.
- Reconcile into two independent fields by phone_normalized.
- Keep platform-specific exception tables for blanks and unmatched rows.
Interpret four combinations
| Messenger | Supported fact | Unsupported inference | |
|---|---|---|---|
| Yes | Yes | Both tasks returned signals | Permission or high intent |
| Yes | No/not returned | Only Facebook returned in this run | Messenger is permanently unavailable |
| No/not returned | Yes | Only Messenger returned in this run | No Facebook account exists |
| No/not returned | No/not returned | Neither returned in this run | Invalid phone or no social use |
| Unknown | Result | One task cannot be interpreted | The other replaces unknown |
CRM schema
| Field | Example | Source |
|---|---|---|
| facebook_registration | registered/not_returned/unknown/error | Facebook Excel |
| facebook_checked_at | ISO datetime | Facebook task |
| messenger_registration | registered/not_returned/unknown/error | Messenger Excel |
| messenger_checked_at | ISO datetime | Messenger task |
| channel_preference | facebook/messenger/other | User choice |
| permission_scope | support/updates/promotion | Permission evidence |
| opt_out_at | Datetime | Opt-out record |
Use platform state in channel decisions
Start with explicit preference and permission, then check whether the relevant task returned a platform signal, and finally review real replies and service completion. A positive result on another platform does not override a single-channel permission.
Data-quality controls
- Retain TXT versions or hashes for both tasks.
- Reconcile accepted, returned, and exception counts.
- Map each phone consistently back to CRM.
- Never overwrite one platform with the other.
- Keep not_returned, unknown, and error distinct.
- Retain check dates and task IDs.
Frequently asked questions
Does Facebook registration imply Messenger registration?
Do not infer one task from the other. Run Messenger Registration Check when that platform signal is needed.
Does Messenger checking read chats?
No. The current Registration Check fields are Phone and Registration Status, not messages, contacts, replies, or activity.
Can both results become “social reachable”?
A summary view is possible, but the underlying platform fields and permission must remain separate. Registration is not reachability authorization.
Facebook and Messenger checks add two independent, dated platform-state signals to one list. Similar field names do not make the evidence interchangeable.
