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

Telegram Bot API 10.1 vừa ra mắt Rich Messages — đây là những gì thay đổi (và không thay đổi) cho các đội nhận tin — UnifyPort

Ngày 11 tháng 6, Telegram phát hành Bot API 10.1 — và lần này, changelog xứng đáng với sự phấn khích. Bot giờ có thể gửi tin nhắn rich với bảng, tiêu đề, danh sách lồng nhau, media nội tuyến, phần thu gọn, công thức toán, chú thích cuối trang và khối trích dẫn. Phương thức mới sendRichMessageDraft cho phép streaming tin nhắn theo thời gian thực — AI agent có thể đẩy phản hồi “đang suy nghĩ” dần dần thay vì gửi một khối text lớn sau khi chờ đợi. Độ dài tin nhắn tối đa tăng lên 32.768 ký tự, với nút “Xem thêm” xuất hiện sau khoảng 8.000 ký tự đầu tiên.

Trong vài ngày, tất cả thư viện bot lớn — python-telegram-bot, puregram, Telegraf — đều mở issue theo dõi hỗ trợ 10.1. Các framework AI agent bắt đầu tạo ticket để thay thế rendering Markdown bằng block RichMessage mới. Nếu bạn phát triển Telegram bot, đây là bản nâng cấp định dạng lớn nhất kể từ MarkdownV2 ra mắt năm 2019.

Nhưng nếu đội của bạn nhận tin nhắn trên Telegram và các nền tảng khác, đáng để hỏi một câu sắc hơn: liệu những cập nhật này có thay đổi pipeline nhận tin của bạn không?

Bot API 10.1 thực sự thêm gì

Các tính năng mới đều nằm ở chiều gửi — cách bot định dạng và gửi tin nhắn cho người dùng:

Tính năngPhương thứcChức năng
Định dạng richsendRichMessageBảng, tiêu đề, danh sách, media nội tuyến, công thức, khối thu gọn, chú thích
Phản hồi streamingsendRichMessageDraftStreaming tin nhắn khi đang tạo — thiết kế cho AI agent
Độ dài mở rộngTối đa 32.768 ký tự (trước đó giới hạn hiệu quả ~4.096)
Kết quả inline richInputRichMessageContentĐịnh dạng rich trong inline query, guest mode và Web App query
Hỗ trợ chỉnh sửaeditMessageTextTham số rich_message mới để chỉnh sửa tin nhắn rich đã gửi

Tất cả tính năng này cải thiện điều bot có thể nói. Không tính năng nào thay đổi điều bot có thể nghe. Object Update — cấu trúc dữ liệu Telegram đẩy cho bot khi người dùng nhắn tin — hoàn toàn giống như trước 10.1. Tin nhắn text từ người dùng vẫn đến dưới dạng message update với trường text. Media vẫn đến dưới dạng photo, document, voice… Schema inbound không đổi vì không cần đổi: người dùng không gửi bot tin nhắn rich có công thức LaTeX và phần thu gọn.

Tại sao điều này ít quan trọng hơn vẻ bề ngoài cho đội đa nền tảng

Nếu Telegram là kênh duy nhất của bạn, 10.1 rõ ràng là tin tốt. Phản hồi của bot đẹp hơn, streaming output của AI agent mượt hơn, và bạn không cần vật lộn với quy tắc escape MarkdownV2 nữa.

Nhưng phần lớn đội nhận tin nhắn inbound năm 2026 không chỉ dùng Telegram. Họ đồng thời xử lý WhatsApp DM, tin nhắn LINE, hội thoại TikTok Shop, mention trên X, và tin nhắn Zalo OA — vấn đề không phải là định dạng phản hồi gửi đi, mà là gom tất cả tin nhắn đến vào một chỗ, một định dạng, đủ nhanh để đáp ứng SLA.

Đây là những gì API chính thức của mỗi nền tảng cung cấp cho việc giao tin nhắn inbound:

Nền tảngPhương thức inbound chính thứcĐịnh dạngChi phíThời gian thiết lập
TelegramBot API webhook (setWebhook)Telegram Update JSONMiễn phíVài phút
WhatsAppCloud API webhookĐịnh dạng Meta webhookTính phí theo tin + phí BSPVài ngày – vài tuần
LINEMessaging API webhookLINE event JSONHạn mức miễn phí, vượt thì tính phíVài ngày – vài tuần (chỉ 3 quốc gia)
XAPI v2 (polling hoặc filtered stream)X API JSON$0.001–$0.20/lần gọiVài giờ – vài ngày
TikTokKhông có DM API chungKhông có đường lập trình
ZaloOA API webhookZalo event JSONGiá OA phân cấpVài ngày – vài tuần

Sáu nền tảng, sáu mô hình xác thực, sáu định dạng webhook, sáu cấu trúc chi phí. Telegram Bot API 10.1 làm mạnh hơn một cột trong bảng này — cột định dạng gửi đi của Telegram — nhưng không thay đổi hàng thực sự quyết định độ phức tạp tích hợp: định dạng dữ liệu tin nhắn đến.

Vấn đề inbound là chuẩn hóa định dạng, không phải định dạng

Đội inbound đa nền tảng cần không phải là định dạng gửi đi phong phú hơn trên bất kỳ kênh đơn lẻ nào, mà là một sự kiện inbound đã chuẩn hóa — trông giống nhau bất kể tin nhắn đến từ nền tảng nào — để một webhook handler, một đường xác minh chữ ký, một hàm routing bao phủ cả sáu kênh.

Đó là điều UnifyPort cung cấp. Kết nối tài khoản — Telegram, WhatsApp, LINE, TikTok, Zalo, X — mọi tin nhắn inbound đều đến webhook của bạn dưới dạng sự kiện message.received với schema chuẩn hóa thống nhất:

{
  "event": "message.received",
  "data": {
    "account_id": "acct_tg_support",
    "provider": "telegram",
    "chat_id": "chat_7d3a1f",
    "sender": "user_9c4b2e",
    "message": {
      "id": "tg_msg_8e1f4a",
      "type": "text",
      "text": "Chào, sản phẩm này có size L không ạ?",
      "reply_token": "rt_3f7b9c..."
    },
    "timestamp": 1750636800
  }
}

Đổi provider thành whatsapp, line hay tiktok — cấu trúc dữ liệu hoàn toàn không đổi. Handler của bạn xác minh một chữ ký HMAC-SHA256 bằng signing_secret đã đặt khi tạo webhook, rồi route tin nhắn — không cần SDK riêng từng nền tảng, không cần logic parse riêng từng kênh, không cần rẽ nhánh sáu hướng theo định dạng sự kiện.

Không cần phê duyệt API chính thức hay xác minh doanh nghiệp. Tài khoản cá nhân và tài khoản thường đều hoạt động. Không tính phí theo tin nhắn và không xếp hàng phê duyệt template.

Thực sự nên làm gì với 10.1

Nếu bạn đang phát triển Telegram bot: nâng cấp thư viện và bắt đầu dùng sendRichMessage. Khả năng định dạng thực sự ấn tượng, và streaming qua sendRichMessageDraft là cải tiến rõ ràng cho bot AI tạo phản hồi dài.

Nếu bạn nhận tin nhắn trên nhiều nền tảng: 10.1 không thay đổi kiến trúc inbound của bạn. Tin nhắn người dùng gửi cho bạn vẫn đến cùng định dạng như trước — trên Telegram cũng như mọi nơi khác. Thách thức tích hợp vẫn là gom sáu định dạng inbound khác nhau vào một handler, và đó chính là lớp mà webhook thống nhất loại bỏ công việc riêng từng nền tảng.

Telegram phát hành một cây cọ tốt hơn. Hệ thống ống nước — đưa tin nhắn từ khách hàng đến đội của bạn — là một bài toán khác, và bản chất nó không phụ thuộc nền tảng.