2.2 Asking for a phone number

Most workflows don't need a phone number once BSUIDs work end to end. Some do: authentication templates, delivery drivers who call ahead, handing a record to a system you don't control. For those, you have two paths.

Ask for it in the thread

Meta added a REQUEST_CONTACT_INFO button that renders as a single tap for the user. It can go on a utility or marketing template:

{
  "type": "buttons",
  "buttons": [
    { "type": "REQUEST_CONTACT_INFO" }
  ]
}

Or be sent as a free-form interactive message inside the 24-hour window:

{
  "type": "interactive",
  "interactive": {
    "type": "request_contact_info",
    "body": { "text": "Share your number so the driver can call you." },
    "action": { "name": "request_contact_info" }
  }
}

You can't customise the button label, and WhatsApp renders it in the user's own language, so there's nothing to translate. Give the body text a reason: this is a consent prompt, and a bare request converts badly.

The reply

Tapping the button triggers a contacts webhook, which picked up three new fields of its own in the same wave:

{  "messages": [    {      "type": "contacts",+      "from_user_id": "US.13491208655302741918",      "contacts": [        {+          "origin": "contact_request",+          "vcard": "BEGIN:VCARD...",          "phones": [            { "phone": "+16505551234", "wa_id": "16505551234" }          ]        }      ]    }  ]}

The field to branch on is origin:

• contact_request means they tapped your button. You get the phone number, no vCard.
• other means they shared a contact card in the chat themselves, which may be somebody else's card entirely. You get a full vCard.

Treat the second case with suspicion. A shared contact isn't proof of the sender's own number.

The contact book

The second path needs no integration work. Meta hosts a contact book per business portfolio, and once you exchange a message or call with a phone number, Meta records that number alongside the BSUID. From then on, webhooks include the phone number regardless of whether the user adopted a username.

Three limits:

• It only captures interactions that happened after the feature launched. Nothing is backfilled.
• It's scoped to a portfolio and isn't shared across portfolios, even ones enrolled in the same parent BSUID account.
• It can be turned off in Business settings, and turning it off deletes what it holds. That isn't reversible.

There's also a delete endpoint for removing a single user's entry, which is what you use when someone asks you to erase their data.

Expect some customers to decline, and more over time. Keeping the number private is the point of adopting a username in the first place, so the customers most likely to refuse are the ones whose number you no longer have.