Best WhatsApp API Providers for BSUID and Username Support
Meta ships the capability, vendors expose it at different speeds. What Infobip, Twilio, Kapso, Wati and the Cloud API actually document for business-scoped user IDs in August 2026.
Every WhatsApp API provider is now shipping the same underlying change, because Meta is the one shipping it. Since April 2026 a business-scoped user ID arrives in every messages webhook, and from July 2026 it works as a recipient address on its own. What separates the providers is how much of that they have actually exposed in their own API, and how much they have left you to work out.
This is a comparison of what each vendor documents today, in August 2026. It only lists capability that is published in the provider's own docs. Where a vendor has written guidance for customers but not documented the field, that is called out as guidance rather than support, because those are different things when you are the one writing the integration.
What a BSUID actually is
A BSUID is a business-scoped user ID. Meta defines it as a unique user identifier that can be used to message a WhatsApp user when you do not know their phone number. It carries the user's two-letter country code, a period, then up to 128 alphanumeric characters, so a real one reads US.13491208655302741918. Enterprise portfolios also get a parent identifier shaped US.ENT.506847293015824.
The identifier is scoped to your business portfolio and that specific user, so the same customer looks different at every company they message. It arrives whether or not the person has adopted a username. Phone numbers still arrive too, under conditions covered in the WhatsApp username and BSUID reference: you messaged or called them in the last 30 days, they messaged or called you in the last 30 days, or they are in your contact book.
Provider comparison
| Provider | BSUID in inbound payloads | Send addressed by BSUID | Contact book and contact info request | What they publish |
|---|---|---|---|---|
| Meta Cloud API (direct) | Yes, in the user_id parameter of every messages webhook | Yes, set recipient and omit to | Both, contact book from early April 2026 | Full reference documentation for business-scoped user IDs |
| Infobip | Yes, as contact.userId, with contact.username and contact.parentUserId | Yes, the to field accepts a phone number or a BSUID | Both, including the REQUEST_CONTACT_INFO template button | Named fields, plus the authentication template exception |
| Twilio | Yes, a new ExternalUserId field across all message webhooks | Yes, in the whatsapp:CC.BSUID format | Notes Meta's contact book behavior | A changelog entry dated February 18 2026 with the field and length limit |
| Kapso | Yes, as business_scoped_user_id, parent_business_scoped_user_id and username | Yes, via the recipient parameter | Documents the contact book as portfolio-scoped | Field-level docs across contact, conversation, message and workflow payloads |
| Wati | Tells customers to export contacts and confirm the BSUID field is present | Not documented publicly | Not documented publicly | Customer guidance on preparing systems and planning for OTPs |
| Chatwoot | Tracked in a public issue, open since March 18 2026 | Tracked in the same issue | Not documented | An open GitHub issue titled "BSUID support needed before June 2026" |
Vonage and Gupshup have both published customer-facing support articles about usernames and business-scoped user IDs. Their public help center pages were not readable at the time of writing, so neither is listed in the capability table above. Treat their support articles as the starting point and confirm the exact field names with their teams before you build.
Best WhatsApp API provider for BSUID support
On documented capability, Infobip is the most complete today. It names the inbound fields, states that the to field accepts either a phone number or a BSUID, ships the contact book, and exposes the REQUEST_CONTACT_INFO template button for asking a customer to share their number inside the conversation. It is also the only provider that publishes the exception that matters most in production, which is covered below.
Twilio is the clearest for developers who want a small, precise change. One new field, one documented format, one length limit, one dated changelog entry. If your integration already treats Twilio as raw plumbing, this is a half-day of work rather than a project. Twilio also documents the length ceiling explicitly: 140 characters including the whatsapp: prefix.
Kapso documents the widest surface, surfacing the identifier in contact, conversation, message and workflow payloads rather than only on the inbound message. That matters if you build automation on top of conversation state rather than on individual messages.
Going direct to Meta's Cloud API gives you every capability first, with no vendor lag, and no vendor abstraction to work around when Meta changes something again. The tradeoff is that you own the whole integration. For teams weighing that call, the Twilio and Cloud API comparison lays out the cost difference on the same volume.
The exception that will bite you
Infobip documents a limit the others do not spell out clearly: a BSUID is a valid recipient for any message type except one-tap, zero-tap and copy code authentication templates, which still require a real phone number.
Read that again if you deliver one-time passcodes. Those three template types are the fast, low-friction OTP formats, and they are precisely the ones that will not accept an identifier. A customer who signs up with a username and never shares a number cannot receive a one-tap OTP from you at all. The fix is to ask for the phone number inside the conversation before you need it, which is what the contact info request button exists for. If OTP delivery is a core flow, plan it now rather than discovering it during an incident. The WhatsApp OTP API guide covers which template type does what.
What to change in your stack
The integration work is small and boring, which is why it gets deferred until it is urgent. Four things:
Size the column properly. A phone number fits in 15 characters. A BSUID needs the two-letter prefix, a period and up to 128 alphanumeric characters. Twilio's prefixed form runs to 140. Every truncation bug in this rollout traces back to a column sized for E.164.
Stop assuming the sender is a phone number. Any code path that parses the from field as E.164, validates it, or uses it as a primary key needs to accept an identifier instead. Match on the BSUID first and fall back to the phone number, not the other way round.
Listen for regeneration. Meta regenerates a BSUID when the user changes their phone number, and fires a system messages webhook when it happens. Ignore that event and one person quietly becomes two records. If your customer data crosses a warehouse or a chain of internal services on its way to the CRM, the new identifier has to propagate through every hop, which is the kind of change that is much easier with a managed layer between your apps and databases than with a pile of one-off scripts.
Capture it on every inbound message. The BSUID arrives whether or not the customer uses a username, so there is no reason to wait for adoption in your region. Storing it now costs one column and turns a future migration into a no-op. The webhook setup walkthrough covers where in the payload to read it and how the retry behavior works when your endpoint is down.
Does this change what you are allowed to send?
No. Usernames change addressing, not permission. Opt-in is still required, template categories and approval still apply, messaging limits and quality rating still cap your daily volume, and purchased lists are still prohibited. A BSUID is not a way to reach someone who never opted in, and treating it as one is the fastest route to a quality rating problem. The bulk messaging rules are unchanged by this rollout.
How to choose
If you are already on one of these platforms, the honest answer is that switching providers over BSUID support alone is rarely worth it. Meta sets the capability, and the vendors that have not documented it yet are implementing it, not refusing it. Ask your provider two questions: which field carries the identifier in your inbound payloads today, and can you address an outbound message by BSUID today. A vendor that cannot answer both in August 2026 is behind, and that is useful information about how they will handle the next platform change too.
If you are choosing fresh and your product depends on identity plumbing, pick on documented depth rather than marketing. Infobip and Kapso publish the most field-level detail. Twilio publishes the cleanest single change. Direct Cloud API gives you everything first and hands you the maintenance.
Whichever you pick, the same preparation applies underneath: store the identifier, stop trusting the phone number to always be there, and reactivate dormant contacts before their numbers age out of the 30 day window. Campaign tooling that keys on a stable identifier rather than a phone string is going to age better than tooling that does not.