The other side of the change is outbound: replying to someone whose phone number you don't have.
This chapter is for you if you choose the identifier yourself. If you send by conversation or by contact and your provider resolves the recipient for you, which is what Kapso does, the rest of this chapter is background.
A second recipient field
Rather than overloading to, Meta added a separate field, so the send payload now has two ways to address a person:
{ "messaging_product": "whatsapp", "recipient_type": "individual", "to": "16505551234", "recipient": "US.13491208655302741918", "type": "text", "text": { "body": "On its way." }}
to takes a phone number. recipient takes a BSUID or a parent BSUID.
Use one or the other, or both. The rule when you send both:
Phone number wins
If to and recipient are both present, Meta uses the phone number and ignores the BSUID.
The response then looks exactly as if you had sent the phone number alone: wa_id comes back and user_id is omitted. If you were relying on the response to tell you which identifier Meta used, it won't.
Sending both is still the right default. For the customers whose phone number you have, it keeps you on that path, which keeps their phone number flowing into your webhooks through the 30-day rule from Chapter 0.2. For the ones whose number has already stopped arriving, it falls back to the BSUID without a second code path.
Validate the format
BSUIDs must be sent whole: country code, period, and every alphanumeric character. If you strip the prefix or normalise the case, the request fails. Assert the shape before you send, since the parent variant adds a segment:
/\A[A-Z]{2}\.(?:ENT\.)?[A-Za-z0-9]{1,128}\z/iA cheap guard here turns a rejected send into a caught bug, and it stops a caller that can't tell the two apart from writing a BSUID into a phone number column.
What you can't send to a BSUID
One category is excluded. One-tap, zero-tap and copy-code authentication templates require a phone number and can't be delivered to a BSUID. Attempting it returns:
131062 Business-scoped User ID (BSUID) recipients are not supported for this message.This matters most if you send one-time passcodes. A customer who adopts a username and whose 30-day window lapses becomes unreachable for authentication until you get a phone number back, which the next chapter covers.
Everything else works: text, media, interactive messages, flows, and ordinary utility and marketing templates.
Calls and blocks
The same to and recipient split applies to the Calling API. The Block Users API uses a different pair, user and user_id, with the same precedence rule, and it doesn't accept parent BSUIDs at all.
If you wrapped these endpoints behind one internal “send to customer” helper, that helper is the right place to resolve identity once and apply the correct field names per endpoint, rather than teaching every caller the difference.