← Tất cả bài viết
So sánh

Guest Mode của Telegram và Webhook đầu vào hợp nhất: Cái nào thực sự giải quyết bài toán nhắn tin đa nền tảng? — UnifyPort

Vào tháng 3 năm 2026, Telegram phát hành Bot API 9.5 và âm thầm giải quyết một vấn đề khiến các nhà phát triển bot đau đầu nhiều năm: điều gì xảy ra khi ai đó @ bot của bạn trong một nhóm chat mà bot chưa từng được thêm vào? Trước đây, câu trả lời là “không gì cả” — bot không nhận được tin nhắn, không thấy nhóm chat, và không thể trả lời. Guest Mode đã thay đổi điều đó. Chỉ cần bật trong cài đặt BotFather, bot của bạn sẽ nhận được một cập nhật guest_message và có thể gửi lại một câu trả lời qua answerGuestQuery, mà không cần tham gia nhóm đó.

Nếu bạn đang xây dựng bot Telegram, đây là một tính năng mới rất hữu ích. Nhưng nếu bạn đang xây dựng các agent hoạt động trên cả Telegram, WhatsApp, LINE, Zalo, TikTok và X, thì tính năng này chỉ giải quyết khoảng một phần sáu vấn đề thực sự của bạn — và đáng để làm rõ chính xác là phần nào.

Guest Mode thực sự làm gì

Cơ chế ở đây khá hẹp và được định nghĩa rõ ràng. Khi người dùng @ bot của bạn trong một cuộc chat được hỗ trợ, hoặc trả lời một tin nhắn trước đó của bot, Telegram sẽ gửi một Update chứa guest_message, kèm theo một token dùng một lần guest_query_id, và các định danh guest_bot_caller_user cùng guest_bot_caller_chat. Bot của bạn gọi answerGuestQuery với token đó và nhận lại một đối tượng SentGuestMessage. Một lượt @ — một lượt trả lời.

Đó là toàn bộ tương tác. Telegram nói rõ các giới hạn:

  • Không có lịch sử chat. Bot chỉ thấy tin nhắn kích hoạt tương tác này, không thấy gì trước đó.
  • Không có danh sách thành viên. Không thể liệt kê ai đang ở trong nhóm chat.
  • Không có sự hiện diện thường trực. Trừ khi được @ hoặc trả lời lần nữa, bot sẽ không nhận được thông báo về các tin nhắn tiếp theo trong nhóm chat đó.
  • Một lượt hỏi — một lượt trả lời. Đây là một primitive theo kiểu request/response, không phải subscription.

Đối với một nhóm bot nhất định — như bot tra cứu tài liệu thường bị @ trong các nhóm chat dev ngẫu nhiên, bot đổi đơn vị, trợ lý dịch thuật — đây là giải pháp rất phù hợp. Nó nhẹ, là tùy chọn (admin nhóm không cần thêm bot vào, người vận hành bot chỉ cần bật một công tắc trong MiniApp của BotFather), và loại bỏ rào cản “vui lòng thêm @MyBot vào nhóm này” — thứ đã giết chết khả năng được sử dụng của không ít bot tiện ích.

Vấn đề mà nó không giải quyết được

Guest Mode là một tính năng hoàn toàn thuộc về Telegram. Nó được triển khai trong stack client và server của Telegram, được expose qua Bot API của Telegram, và được kích hoạt bởi hành vi UI riêng của Telegram (lượt @ hoặc trả lời trong một cuộc chat Telegram). Không có gì trong số đó chuyển sang được nền tảng khác.

Nếu team của bạn đang chạy quy trình hỗ trợ hoặc agent trên nhiều hơn một kênh — điều này gần như là tiêu chuẩn cho hầu hết các team làm tự động hóa hướng khách hàng vào năm 2026 — thì câu hỏi “bot của tôi được kéo vào một cuộc trò chuyện như thế nào khi chưa được thêm vào một cách chính thức” không phải là vấn đề riêng của Telegram. Vấn đề có hình dạng tương tự cũng tồn tại trên:

  • WhatsApp — khách hàng nhắn trực tiếp đến một số điện thoại, và hệ thống của bạn cần xử lý tin nhắn đó mà không có một đối tượng “cuộc trò chuyện” sẵn có
  • LINE — người dùng theo dõi một Official Account và bắt đầu nhắn tin, không liên quan gì đến khái niệm “nhóm”
  • X — ai đó nhắn DM cho tài khoản của bạn, hoặc @ nó trong một reply
  • TikTok và Zalo — mỗi nền tảng có định dạng tin nhắn đầu vào riêng

Telegram đã giải quyết phiên bản của riêng họ cho vấn đề “nhận một tin nhắn gửi đến bạn, từ một nơi mà trước đó bạn không theo dõi một cách rõ ràng”. Nhưng nếu bạn xây dựng pipeline đầu vào xung quanh guest_message và answerGuestQuery, bạn chỉ đang xây dựng cho một phần sáu các kênh của mình. Năm kênh còn lại cần tích hợp riêng, mô hình xác thực riêng, định dạng sự kiện riêng — và các giới hạn đặc thù của Guest Mode (không lịch sử, một lượt trả lời, cần kích hoạt lại) thậm chí không khớp gọn gàng với cách hoạt động của hội thoại trên WhatsApp hay LINE.

Hình dạng thực sự của vấn đề

Bỏ qua các cơ chế đặc thù của từng nền tảng, điều mà mọi team trong tình huống này thực sự muốn là cùng một thứ: một sự kiện được chuẩn hóa duy nhất, được kích hoạt mỗi khi có tin nhắn gửi đến một trong các tài khoản của bạn, bất kể nó đến từ nền tảng nào, cộng với một endpoint duy nhất để gửi trả lời.

Đó không phải là một tính năng của Telegram. Đó là một lớp tích hợp — và đó chính là lý do UnifyPort tồn tại.

Webhook hợp nhất bao quát cùng phạm vi trên sáu nền tảng như thế nào

Webhook của UnifyPort phát ra một sự kiện message.received duy nhất cho tin nhắn đến trên bất kỳ kênh đã kết nối nào:

{
  "event": "message.received",
  "account_id": "acct_8Q2vK",
  "provider": "telegram",
  "from": "user_3f9c1a",
  "text": "Hey, are you open on weekends?",
  "timestamp": 1749427200,
  "message_id": "tg_msg_5d2b7e"
}

Đổi provider thành whatsapp, line, zalo, tiktok, hoặc x, hình dạng của sự kiện không thay đổi — chỉ giá trị của trường đó thay đổi. Handler của bạn không cần phân nhánh theo sáu SDK khác nhau hoặc sáu định dạng webhook khác nhau; nó chỉ cần kiểm tra evt.event === "message.received" một lần, và evt.provider cho biết nên trả lời qua kênh nào nếu điều đó quan trọng.

Việc trả lời cũng tương ứng đối xứng: một lệnh gọi POST /v1/messages duy nhất, xác thực bằng Bearer API key, định địa chỉ qua account_id và from — cùng một lệnh gọi bất kể tin nhắn đến từ nền tảng nào. Mọi lượt gửi đến webhook của bạn đều được ký bằng HMAC-SHA256 sử dụng signing_secret bạn đã cấu hình, vì vậy việc xác minh cũng chỉ là một đoạn code duy nhất, không phải sáu.

Telegram ─┐
WhatsApp ─┤
  LINE   ─┼──► UnifyPort ──► message.received ──► webhook của bạn
  Zalo   ─┤         ▲                                   │
 TikTok  ─┤         │                                   ▼
   X     ─┘    POST /v1/messages ◄──────────── logic trả lời của bạn

Trong khi Guest Mode yêu cầu admin nhóm (hoặc chính ngữ cảnh hội thoại) @ bot của bạn trước khi nó có thể hành động, các sự kiện đầu vào của UnifyPort kích hoạt theo trigger gốc của từng nền tảng — DM, follow, reply — và được dịch sang cùng định dạng message.received mỗi lần. Bạn không phải chờ một tín hiệu đặc thù của Telegram để rồi tái tạo nó trên năm nền tảng khác không có cơ chế tương đương.

Đối với các team ở Việt Nam, cả WhatsApp và Zalo đều quan trọng — và đây chính là nơi điều này có ý nghĩa thực tiễn nhất: một bot Telegram dùng Guest Mode để bắt mention không giúp gì cho luồng tin nhắn Zalo OA hoặc WhatsApp của bạn. Một webhook message.received chung cho cả ba kênh thì có.

Ý nghĩa trong thực tế

Nếu Telegram thực sự là kênh duy nhất của bạn, và use case của bạn vừa khớp với hình dạng của Guest Mode — đôi khi bị @ trong các nhóm chat bạn không quản lý — thì việc bật nó là đáng làm. Nó miễn phí, gốc (native), và không cần thêm hạ tầng nào.

Nhưng nếu bạn đã vượt qua điểm đó, đang chạy một quy trình agent hoặc hỗ trợ cần nhận tin nhắn trên Telegram và WhatsApp và bất kỳ kênh nào khác mà khách hàng của bạn sử dụng — xây dựng xung quanh các primitive đặc thù của Telegram nghĩa là phải xây lại cùng một logic thêm năm lần nữa, mỗi lần cho một nền tảng, mỗi nền tảng lại có những điểm kỳ quặc riêng. Một webhook hợp nhất gom tất cả việc đó thành một lần tích hợp duy nhất. Kết nối các kênh của bạn và xem tài liệu tham khảo message.received — và nếu bạn định đưa nó cho một AI coding agent để dựng phần nhận tin nhắn, đây là cách quy trình xây dựng đó diễn ra trong thực tế.