Business-scoped user IDs | Developer Documentation

Check WhatsApp usernames and user IDs in ChatArchitect

If a WhatsApp conversation reaches your connected tool with a user identifier instead of a phone number, review the supported identity mapping before creating or merging a customer record. A visible username and a backend business-scoped user ID have different roles.

The ChatArchitect API quick start documents a phone-based incoming example and phone destinations for sending. It does not specify BSUID fields, replies addressed to those IDs, parent-ID enrollment or automatic CRM migration. Confirm those capabilities for the exact connection with support; do not substitute an ID into the documented phone destination.

Identify which value you received

Meta describes BSUIDs as scoped to a business portfolio and user; a changed username does not itself change the BSUID. A number change can regenerate the ID. Its format includes a country prefix, a period and an identifier; a parent ID includes ENT. These definitions do not establish ChatArchitect's field mapping or sending support.

Do not turn an identifier prefix into a phone number or change the identifier's spelling. For example, removing punctuation or converting it into a numeric CRM field can prevent an exact match. Record a missing value as missing rather than guessing it from a name or country.

When a phone number is absent

Meta's username flow can omit phone data in provider events. It also describes a Meta-hosted contact book that affects available contact information. This is separate from automatic import into a CRM or the Business app address-book workflow.

Confirm how the receiving integration represents an identifier-only conversation and which route it supports for a reply. Missing phone data alone does not establish a failed receipt. If your workflow requires a phone number that is unavailable, arrange an appropriate customer contact or verification process with the responsible team. A special Meta contact-request button is not established as a ChatArchitect feature by this guide.

Match the connection before updating a customer record

1. Identify the connected business number or account and the receiving CRM, help desk or custom application.
2. Inspect the actual supported sample. Record which fields contain a phone number, display value, user ID and any parent ID; confirm which can be absent.
3. Match the identifier using the integration's established business scope. An ID from another connection is not automatically a universal customer key.
4. Compare the proposed customer association with existing conversations and tasks. Keep an ambiguous match for review instead of combining records by their display names.
5. For a number or user-ID change, review any provided previous/current values and the supported update rule before changing future destinations.
6. After an authorized change, inspect conversation ownership and the destination used by affected sending workflows separately.

Verify identifier-only handling before relying on it

Obtain a redacted supported example from ChatArchitect for your connection. In a controlled local parser check, cover the fields that example permits: phone plus ID, ID without phone and any confirmed identifier-change notice. Check that absent phone data does not produce an empty conversation, an invented number or an unrelated record.

Use the message-routing checklist to separate incoming traffic from delivery results. For a coexistence connection, confirm identity handling for live traffic, history and app sends independently. A provider-side test or successful plain text receipt does not establish BSUID-targeted sending through ChatArchitect.

Review dependent audience and reporting processes

Check which identifier each CRM audience, automation and reporting process uses. A new identifier can otherwise split a conversation or count one record twice. Do not infer a change to your ChatArchitect tariff, active-customer accounting or campaign permission from an identifier format alone.

For marketing preferences, use the confirmed individual-customer mapping and scope. Parent identifiers do not automatically apply one person's stop/resume preference to other customer records.

If the match or reply route is unclear

• Conversation has an ID but no number: confirm the supported display and reply route rather than filling the phone field with that ID.
• Two customer records appear: compare the business connection, identifiers, history and matching rule before approving consolidation.
• Reply fails after a record update: preserve the original attempt and result, then check the destination and account scope with support.
• Display name or username changed: review it as a display update; do not assume a verified customer identity changed.

Keep provider changes separate from the customer contract

See Meta's current BSUID reference for provider definitions and its change history. It includes direct Meta APIs, rollout details and configuration options that are not instructions for a ChatArchitect customer. For support, provide the connection, integration version, time and redacted field/matching examples using the data-handling guide.