Result guide
How to interpret WhatsApp verification results
A WA Lookup response separates a completed registration decision from invalid input, rate limits, insufficient balance, and temporary service failures. This guide shows which fields can be used, which conclusions they support, and which conclusions remain outside the product scope.
Reviewed July 21, 2026
What does registered mean?
registered=true means the completed check reported that the submitted E.164 number was registered on WhatsApp at request time. registered=false means the completed check reported it was not registered. If the request failed or was undetermined, there is no true-or-false decision and the workflow should retry or review it instead of writing false.
Read the envelope before the product fields
The HTTP status and response code describe whether the request produced a usable result. Product fields should only be consumed after that outcome is understood.
| Response | Classification | Store as |
|---|---|---|
| Success + registered=true | Completed registered result | registered=true with request timestamp |
| Success + registered=false | Completed unregistered result | registered=false with request timestamp |
| 400 | Invalid product, body, or number | Input error; correct before retry |
| 402 | Insufficient account balance | Billing block; no number decision |
| 429 | Rate or concurrency limit | Retryable control response; no number decision |
| 503 or undetermined | Temporary service outcome | Pending/retry; never coerce to false |
Interpret additional fields independently
Avatar and Business fields answer narrower questions. Their absence or false value must not overwrite the registration field.
- avatar=true reports avatar availability for that check; avatar=false does not mean the number is unregistered.
- avatar_url may be empty when no retrievable URL is available and should be treated as optional output.
- business=true reports the Business account flag; business=false does not prove the account is personal, inactive, or unaffiliated with a company.
- Use the product code alongside stored fields so consumers know which fields were actually requested.
Design a stable downstream status model
A three-state business model prevents temporary failures from polluting contact data. Keep technical status separate from the last known completed result.
- 1
Completed registered
Store true, the verification time, and the service type.
- 2
Completed unregistered
Store false with the same audit fields; do not merge it with invalid input.
- 3
Pending or retryable
Use for 429, 503, timeouts, and undetermined responses. Preserve any previous completed state until policy decides it is stale.
- 4
Rejected input
Route 400-class validation errors back to normalization or source-data correction.
Conclusions the response does not support
The service checks selected account-status fields. It does not provide identity, behavioral, or consent evidence.
- It does not identify the person or organization controlling the number.
- It does not reveal online status, last seen, messages, groups, or contacts.
- It does not guarantee message delivery or future registration status.
- It does not grant permission to contact the number or replace consent records.