Read who is in a group, look up a contact, and check whether a phone number is on WhatsApp before you message it.
Sending to a number that is not on WhatsApp wastes a call and, at volume, looks like the behaviour of a spammer. Check first - up to a batch at a time - and message only what comes back registered.
is_on_whatsapp is still in the response as a deprecated alias. Read registered in new code.
curl -X POST https://wabridges.com/api/instances/user-123/proxy/contacts/check \
-H "Authorization: Bearer $WA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"phones": ["15550001234", "00000000000"]}'
[
{
"phone": "15550001234",
"jid": "15550001234@s.whatsapp.net",
"registered": true,
"is_on_whatsapp": true,
"is_business": false
},
{
"phone": "00000000000",
"registered": false,
"is_on_whatsapp": false,
"is_business": false
}
]
Run this when a number enters your system, not before every send. The answer changes rarely, and caching it keeps you well inside the rate limit.
Ask by JID and you get the display name, whether the account is a business, and the business fields when it is - name, email, address.
Names come from WhatsApp and from the phone's own address book, so treat them as a display convenience rather than identity. The JID is the identity.
curl https://wabridges.com/api/instances/user-123/proxy/contacts/15550001234@s.whatsapp.net \ -H "Authorization: Bearer $WA_API_KEY"
GET /contacts returns every contact the bridge knows about. On a busy number that is a long list, so treat it as a sync job rather than something you call inside a request.
Avatars are a separate call per contact and return image bytes, not a URL - fetch them lazily and cache what you fetch.
curl https://wabridges.com/api/instances/user-123/proxy/contacts \ -H "Authorization: Bearer $WA_API_KEY"
Group metadata comes back by JID - the subject, the description, when it was created, and how many people are in it.
You get the group JID from the chat_id of any message it sends you, which is the practical reason to store chat_id on every inbound event. In a group, chat_id is the group and contact_id is the person who spoke, and replying to the wrong one is the classic first-integration bug.
curl https://wabridges.com/api/instances/user-123/proxy/groups/120363000000000001@g.us \ -H "Authorization: Bearer $WA_API_KEY"
{
"jid": "120363000000000001@g.us",
"name": "Team standup",
"topic": "daily at 9",
"participants": 12,
"created": 1777180605
}
This is read-only. Creating groups, adding people and changing the subject are not part of the API - do those on the phone.
Something here not matching what you see? Write to us - a person answers.