Free Tool
Meta is rolling out business-scoped user IDs (BSUIDs) across WhatsApp Cloud API webhooks, starting in early April 2026. Depending on your setup (whether users have adopted usernames, your contact book status, and how you send messages), the fields in your webhook payloads will look different.
This checker lets you configure your specific scenario and see exactly which fields will be present, omitted, or conditional across incoming message webhooks, status webhooks, and send-message responses. No account needed: it runs entirely in your browser.
BSUIDs start appearing in message webhooks
Contact book starts rolling out (auto-stores phone + BSUID pairs)
Send messages to BSUIDs via the new recipient field
WhatsApp usernames launch: phone numbers may be omitted from webhooks
Configure your scenario to see which webhook fields to expect.
Has the user adopted a username?
WhatsApp usernames launch later in 2026
Message/call interaction in last 30 days?
Are you in the user's WhatsApp contacts?
Is the user in your contact book?
Contact book started rolling out in early April 2026
Portfolio type
Linked portfolios with parent BSUIDs?
Sending messages scenario
Which identifier are you sending with?
Before July 2026, phone-number sending is the only supported option
contacts[].user_idExpected presentBSUID, the stable identifier
contacts[].wa_idExpected presentPhone number included
messages[].fromExpected presentMirrors wa_id conditions
messages[].from_user_idExpected presentBSUID
contacts[].user_idExpected presentBSUID
contacts[].wa_idExpected presentPresent when the message was sent to a phone number
statuses[].recipient_idExpected presentSet to the user's phone number when sent to a phone number
statuses[].recipient_user_idWill be omittedOmitted when sent to a phone number
toExpected presentPhone number send
recipientConditionalSupported after July 2026, but not used in this phone-send scenario
user_id alongside wa_id. Treat user_id as the stable identifier going forward.wa_id and from may be absent.Your webhook handlers need to work without wa_id and from. Use user_id as your primary identifier and consider enabling Meta's contact book to retain phone numbers from prior interactions. For users who hide their number, the REQUEST_CONTACT_INFO template button lets you ask for it explicitly.
BSUIDs are scoped to the business portfolio that owns the phone number, not yours. Verify WABA and phone number ownership per portfolio before attempting BSUID-based operations.
Update your webhook handlers now to capture user_id alongside wa_id. Treat user_id as the stable identifier going forward. For the full webhook payload tables and implementation details, read the complete BSUID transition guide.
It predicts which webhook fields (user_id, wa_id, from, recipient, etc.) will be present, omitted, or conditional in your incoming message webhooks, status webhooks, and send-message responses based on the scenario you configure.
No. The checker runs in your browser with no sign-up and no server calls. Your configured scenario is not sent to Dualhook.
Now. BSUIDs have appeared in message webhooks since early April 2026. Your webhook handlers should be updated to capture the new user_id field and handle cases where wa_id and from may be absent.
Your existing code will keep working until users adopt usernames (later in 2026). At that point, webhooks for username-adopted users may arrive without wa_id or from, which can break handlers that depend on phone numbers being present.
Yes. On supported message types, use the recipient field with a BSUID or parent BSUID. Dualhook's Runtime API accepts recipient without to. Authentication template types that Meta excludes from BSUID sending still require a phone number.
The complete BSUID transition guide (including webhook payload tables, contact book details, solution provider scoping, and the /contacts endpoint) is available in the Dualhook documentation at /docs/contacts-bsuid.
Documentation
Dive into the full technical documentation and messaging best practices.
14-day free trial, cancel anytime.
16:05