BSUID WhatsApp bắt đầu từ 7/7 — Danh sách 5 điểm cần kiểm tra cho đội ngũ chỉ nhận tin nhắn đến — UnifyPort
Meta đang thay đổi cách WhatsApp định danh người dùng trong API. Bắt đầu từ ngày 7 tháng 7 năm 2026 (Wave 1), một trường mới có tên Business-Scoped User ID (BSUID) sẽ xuất hiện trong mọi webhook payload — và với những người dùng đã kích hoạt tên người dùng WhatsApp, số điện thoại có thể không còn hiển thị nữa.
Nếu bạn nhận tin nhắn WhatsApp để phục vụ hàng đợi hỗ trợ, tích hợp CRM, hoặc pipeline AI agent, thay đổi này ảnh hưởng đến code của bạn. Mức độ ảnh hưởng phụ thuộc vào con đường mà tin nhắn WhatsApp đi qua trước khi đến backend. Điều này cũng quan trọng nếu bạn đang vận hành song song cả WhatsApp lẫn Zalo — hai kênh phổ biến nhất tại Việt Nam — vì chỉ kênh WhatsApp bị ảnh hưởng bởi thay đổi này.
Bài viết này là một danh sách kiểm tra. Năm khu vực cần rà soát, một bảng quyết định, và câu trả lời rõ ràng cho câu hỏi mà hầu hết các đội nhỏ đang thắc mắc: “Tôi có cần làm gì trước ngày 7/7 không?”
BSUID thực sự là gì
Mỗi người dùng WhatsApp sẽ được gán một định danh mới: Business-Scoped User ID. Định dạng gồm mã quốc gia hai chữ cái, dấu chấm, và tối đa 128 ký tự chữ-số — ví dụ VN.1A2B3C4D5E6F7G8H9I0J. Đặc điểm quan trọng: cùng một người nhận BSUID khác nhau cho mỗi doanh nghiệp họ tương tác. BSUID của khách hàng A khi nhắn tin cho bạn hoàn toàn khác với BSUID của cùng khách hàng A khi nhắn tin cho công ty khác.
Lộ trình triển khai của Meta:
| Đợt | Ngày | Phạm vi |
|---|---|---|
| Wave 1 | 7/7/2026 | Các thị trường đầu tiên |
| Wave 2 | 20/7/2026 | Mở rộng |
| Toàn cầu | Tháng 9/2026 | Tất cả thị trường còn lại |
BSUID đã bắt đầu xuất hiện trong webhook payload từ ngày 31/3/2026 dưới dạng trường user_id mới. Nhưng thay đổi gây lỗi thực sự đến vào Wave 1: khi người dùng kích hoạt tên người dùng WhatsApp, số điện thoại có thể không còn xuất hiện trong các trường wa_id và from.
Danh sách kiểm tra: năm khu vực cần rà soát
1. Phân tích webhook payload
Thay đổi: Trường user_id mới xuất hiện trong mọi message webhook. Với người dùng đã bật username, các trường wa_id và from trước đây chứa số điện thoại giờ có thể chứa BSUID — hoặc vắng mặt hoàn toàn.
Cần kiểm tra: Webhook handler của bạn có giả định from luôn là số điện thoại không? Có dùng regex khớp chữ số, dùng làm database key, hay truyền vào thư viện validate số điện thoại không? Tất cả sẽ lỗi khi from chứa VN.1A2B3C4D5E... thay vì 84912345678.
2. CRM và đối chiếu liên hệ
Thay đổi: Nếu CRM lưu bản ghi khách hàng theo số điện thoại, tin nhắn từ người dùng đã bật username có thể đến mà không có số điện thoại. Bạn không thể tra cứu khách hàng.
Cần kiểm tra: Cơ sở dữ liệu liên hệ có thể lưu trữ và đối chiếu theo BSUID song song với số điện thoại không? Meta cung cấp Contact Book API để giữ bản ánh xạ từ số điện thoại sang BSUID từ các cuộc hội thoại trước — nhưng bạn cần gọi API này trước khi số điện thoại biến mất khỏi webhook mới.
3. Lịch sử hội thoại và phân luồng
Thay đổi: Nếu bạn phân luồng hội thoại theo số điện thoại (ví dụ: “hiển thị tất cả tin nhắn từ +84912345678”), tin nhắn của cùng một người sẽ bắt đầu đến dưới BSUID. Lịch sử hội thoại bị chia đôi trừ khi bạn đã liên kết bản ghi cũ theo số điện thoại với BSUID mới.
Cần kiểm tra: Kho tin nhắn có dùng số điện thoại làm khóa chính cho luồng hội thoại không? Nếu có, hãy lên kế hoạch backfill: dùng ánh xạ Contact Book để liên kết bản ghi cũ theo số điện thoại với BSUID trước Wave 1.
4. Template và địa chỉ gửi đi
Thay đổi: Khi gửi template message (outbound), bạn sẽ cần địa chỉ người nhận bằng BSUID thay vì số điện thoại — đặc biệt với người dùng đã kích hoạt username mà số điện thoại không còn hiển thị.
Cần kiểm tra: Nếu bạn gửi tin nhắn chủ động (xác nhận đơn hàng, cập nhật vận chuyển, nhắc lịch hẹn), logic gửi có phân giải người nhận bằng số điện thoại không? Bạn cần lưu BSUID từ tin nhắn đến gần nhất và dùng nó cho các cuộc gọi outbound trong tương lai.
5. Lưu trữ dữ liệu và tuân thủ
Thay đổi: BSUID là một dạng dữ liệu nhận dạng cá nhân mới. Chúng được phân định theo doanh nghiệp (nên không thể dùng để đối chiếu người dùng giữa các công ty), nhưng vẫn là PII theo hầu hết các khung pháp lý về quyền riêng tư — bao gồm PDPA tại Việt Nam.
Cần kiểm tra: Chính sách lưu trữ dữ liệu có bao gồm loại định danh mới không? Nếu bạn có quy trình xóa dữ liệu theo GDPR/PDPA liệt kê tất cả định danh đã lưu của người dùng, BSUID cần được đưa vào danh sách.
Bạn đang ở con đường nào?
Không phải đội nào cũng cần xử lý cả năm mục. Điều này phụ thuộc vào cách tin nhắn WhatsApp đến backend của bạn.
| Hình thức tích hợp | Mục cần xử lý | Mức độ nỗ lực |
|---|---|---|
| Cloud API (trực tiếp) | Cả năm mục | Cao — bạn parse raw webhook của Meta, mọi thay đổi payload ảnh hưởng trực tiếp đến code |
| BSP (Wati, 360dialog, v.v.) | Mục 2, 3, 4, 5 | Trung bình — BSP có thể trừu tượng hóa webhook format, nhưng CRM và logic gửi vẫn cần cập nhật |
| Giao diện inbound không chính thức | Không có | Không cần làm gì — đọc tiếp |
Tại sao inbound không chính thức không bị ảnh hưởng
Nếu tin nhắn WhatsApp của bạn đến qua giao diện không chính thức của UnifyPort, việc chuyển đổi BSUID không chạm đến pipeline của bạn. Lý do: UnifyPort không định tuyến tin nhắn qua Cloud API của Meta. Con đường không chính thức kết nối trực tiếp với WhatsApp — giống cách một chiếc điện thoại chạy WhatsApp — nên tin nhắn webhook bạn nhận chưa bao giờ ở trong định dạng payload Cloud API.
Điều tương tự cũng đúng nếu bạn vận hành Zalo song song với WhatsApp trên UnifyPort — kênh Zalo có pipeline riêng biệt hoàn toàn và không liên quan gì đến thay đổi định danh của Meta.
Webhook của bạn vẫn nhận cùng sự kiện message.received như trước:
{
"event": "message.received",
"account_id": "acct_3qPmRz",
"provider": "whatsapp",
"from": "user_88c1ae",
"text": "Chào, đơn hàng #2241 đã giao chưa?",
"timestamp": 1751875200,
"message_id": "wa_msg_f4e29a"
}Trường from là định danh người dùng chuẩn hóa riêng của UnifyPort — không phải số điện thoại, không phải BSUID. Nó chưa bao giờ là số điện thoại, nên không có gì cần migrate khi Meta thay đổi cơ chế định danh. CRM matching, phân luồng hội thoại, và webhook parsing đều tiếp tục hoạt động bình thường.
Xác thực chữ ký HMAC-SHA256 trên webhook endpoint cũng không bị ảnh hưởng — signing secret và định dạng chữ ký là của UnifyPort, không phải của Meta.
Cần làm gì trong tuần này
Nếu bạn dùng Cloud API hoặc BSP: bắt đầu với mục 1 (phân tích webhook). Ghi log mẫu webhook đến và kiểm tra xem trường user_id đã xuất hiện chưa — nó đã triển khai từ ngày 31/3. Nếu có, payload của bạn đã đang thay đổi. Xử lý các mục 2-5 trước ngày 7/7.
Nếu bạn dùng con đường inbound không chính thức: không có gì thay đổi. Chuyển đổi BSUID là vấn đề của Cloud API, và tin nhắn của bạn không đi qua Cloud API. Cứ tiếp tục xây dựng.