Ask WhatsApp whether this contact's number has an account
POST/api/contacts/:contact/reachability/whatsapp
Answers the question directly, without sending anything to the number.
This exists on ONE transport only. The Cloud API publishes no
endpoint that answers it: the On-Premises API's POST /v1/contacts node
did, and it went away with the On-Premises API itself (final client
version expired 2025-10-23); nothing in the Cloud API reference replaced
it. The contacts[].wa_id returned by POST /{phone-number-id}/messages
is a receipt for a message already delivered and billed, not a lookup.
The WhatsApp Web protocol behind a QR-linked line does carry it, so a
tenant with a QR channel can ask and a tenant with only a Cloud channel
cannot. presence.checkable on the reachability rows says which is
which.
Deliberate and one contact at a time. Nothing bulk calls this: no
import, no schedule, no list view. Bulk enumeration of phone numbers is
what gets a QR-paired account banned, so the restraint is structural —
throttled per contact (asked_recently), per line, and per route.
The result is written as an OBSERVATION with a timestamp, never as a property of the person. A provider outage records nothing at all.
Requires Contact view plus the conversations.reply permission.
Request
Responses
- 200
- 401
- 403
- 422
What we now know, and when we learned it.
Not authenticated. code: account_disabled means the member's seat was deactivated in this workspace: the session is over even though the token was not revoked (clients sign out and clean up).
Authenticated but not allowed.
The lookup did not happen. reason is one of no_qr_channel
(this tenant has no QR-linked WhatsApp line — the Cloud API cannot
answer), no_number (the contact has no international-format
number), asked_recently, or bridge_unavailable.