Trả lời Telegram Webhook: dùng response body hay gọi sendMessage riêng?
Telegram cho phép gọi một phương thức Bot API như sendMessage ngay trong HTTP response trả về cho webhook. Tuy nhiên, tài liệu chính thức nói rõ rằng ứng dụng không thể biết lệnh đó có thành công hay lấy kết quả của nó. Nếu cần lưu mã tin nhắn đã gửi hoặc xử lý lỗi API cụ thể, hãy gọi Bot API riêng. Trả 200 OK để xác nhận nhận bản cập nhật không đồng nghĩa với việc tin nhắn trả lời đã được gửi vào cuộc trò chuyện.
Điểm chính
- Xác nhận HTTP, kết quả phương thức API và việc người dùng đã đọc là ba kết quả khác nhau.
- Nhúng phương thức vào phản hồi giúp giảm một yêu cầu riêng, nhưng không lấy được kết quả.
- Gọi
sendMessageriêng phù hợp khi bước tiếp theo cần mã tin nhắn hoặc bản ghi kết quả gửi. - UnifyPort có hợp đồng khác: nội dung phản hồi webhook bị loại bỏ. Muốn gửi tin nhắn phải gọi API riêng.
Phản hồi Telegram webhook có thể làm gì?
Tài liệu Telegram Bot API mô tả cơ chế đặc biệt: trả tham số bằng application/json, application/x-www-form-urlencoded hoặc multipart/form-data, rồi dùng method để chỉ định phương thức cần gọi.
Ví dụ về hình thức: ứng dụng trả JSON chứa method: sendMessage cùng chat_id và text phù hợp. Đây là tham số gọi phương thức, không phải cấu trúc Update đầu vào. Nó cũng không có nghĩa rằng bất kỳ văn bản nào trong response body sẽ tự trở thành tin nhắn trong cuộc trò chuyện.
FAQ chính thức nêu trực tiếp sự đánh đổi: ít yêu cầu hơn, nhưng không thể biết lệnh thành công hay lấy kết quả. Vì vậy, nhật ký máy chủ ghi nhận HTTP response thành công không thể thay thế kết quả gửi còn thiếu.
Bài viết giả định bot đã nhận được bản cập nhật. Nếu vẫn đang chọn danh tính và cách tiếp nhận, hãy đọc so sánh Telegram Bot API webhook với webhook đầu vào hợp nhất. Chọn polling hay webhook là vấn đề khác với chọn cách trả lời người dùng sau khi nhận dữ liệu.
Nhúng lệnh vào phản hồi hay gọi sendMessage riêng?
| Tiêu chí | Gọi phương thức trong phản hồi webhook | Gọi Bot API riêng |
|---|---|---|
| Cách gọi | Response body chứa method và tham số | Ứng dụng gọi phương thức bằng yêu cầu khác |
| Kết quả phương thức | Ứng dụng không lấy được | Có thể kiểm tra JSON từ Bot API |
| Mã tin nhắn đã gửi | Cơ chế này không trả về | sendMessage thành công trả về Message |
| Xử lý lỗi | Không có kết quả để phân nhánh | Kiểm tra ok, description, error_code được trả về |
| Trường hợp phù hợp | Câu trả lời đơn giản, không cần kết quả gửi | Cần lưu vết, xử lý nền hoặc thực hiện bước phụ thuộc |
Định nghĩa chính thức về response và sendMessage quy định response có ok; kết quả thành công nằm trong result, còn yêu cầu thất bại có thông tin lỗi. sendMessage trả về Message đã gửi khi thành công.
Phương thức thành công vẫn không chứng minh người nhận đã đọc. Ngoài ra, dù gọi riêng, kết quả vẫn có thể không xác định nếu dịch vụ từ xa đã xử lý yêu cầu nhưng phía gọi không nhận được phản hồi.
Tình huống giả định: bot gửi một đoạn hướng dẫn ngắn và không có bước nào cần tham chiếu mã tin nhắn đó. Trả lời ngay trong response có thể đủ. Nếu hệ thống hỗ trợ phải liên kết tin nhắn với phiếu yêu cầu hoặc quyết định bước tiếp theo theo lý do API từ chối, hãy gọi riêng và lưu kết quả thực tế.
Tách xác nhận tiếp nhận khỏi kết quả gửi
Với quy trình xử lý chậm, nên áp dụng thiết kế ứng dụng sau. Đây là khuyến nghị, không phải bảo đảm API bổ sung của Telegram:
- Xác minh nguồn webhook và lưu bền vững bản cập nhật.
- Xác nhận tiếp nhận mà không chờ AI, CRM hay tác vụ gửi hoàn tất.
- Để worker gọi Bot API riêng.
- Ghi kết quả thực tế hoặc lỗi vào tác vụ cục bộ.
- Xem hết thời gian chờ mạng là kết quả chưa xác định, không phải bằng chứng chắc chắn rằng gửi thất bại.
Loại trùng bản cập nhật trong phạm vi từng bot. Một lần chuyển lại phải tìm đến tác vụ đã có, không tạo thêm một câu trả lời độc lập. Đồng thời, chọn một nơi chịu trách nhiệm gửi: không vừa nhúng câu trả lời trong HTTP response, vừa đưa chính câu đó vào hàng đợi để worker gửi.
Telegram mô tả việc thử lại khi chuyển webhook không thành công với trạng thái ngoài 2XY. Đó là thử chuyển lại bản cập nhật đầu vào, không thay thế việc theo dõi kết quả phương thức đầu ra. Nếu đã nhận được bản cập nhật nhưng không thấy câu trả lời, hãy kiểm tra bản ghi gửi trước khi đổi cấu hình webhook. Hướng dẫn chẩn đoán getWebhookInfo giải thích vì sao trạng thái chuyển webhook không chứng minh quy trình nghiệp vụ đã hoàn tất.
Response body của UnifyPort không phải lệnh gửi tin
Giao diện không chính thức của UnifyPort không sử dụng quy ước gọi phương thức bên trong phản hồi của Telegram. Tài liệu chuyển webhook quy định mọi 2xx đều xác nhận tiếp nhận, còn response body được đọc rồi loại bỏ. Trả JSON chứa method: sendMessage không thực thi phương thức đó theo hợp đồng này.
Với tài khoản nhắn tin đã kết nối, hãy nhận message.received, xác minh chữ ký, lưu sự kiện rồi xác nhận tiếp nhận. Khi có signing_secret, X-Device-Signature dùng HMAC-SHA256 trên X-Device-Timestamp, một dấu chấm và các byte nguyên gốc của request body.
Gửi riêng bằng POST /v1/messages, xác thực qua X-Api-Key. Tài liệu gửi tin nhắn văn bản định nghĩa account_id, to.id, to.type, message.type và message.text. Response minh họa có data.status: accepted; không nên diễn giải thành thông báo đã đọc. Worker trả lời tự động cũng cần kiểm tra data.message.direction để tin nhắn do chính tài khoản gửi không tạo vòng lặp trả lời.
Khi đưa Telegram vào cùng quy trình với Zalo hoặc WhatsApp, hãy giữ riêng ý nghĩa xác nhận của từng hợp đồng thay vì mặc định mọi webhook đều hỗ trợ trả lời trong response. Nếu cần danh tính bot, tiếp tục dùng Bot API chính thức. Luồng kết nối tài khoản của UnifyPort là tích hợp khác, không khôi phục kết quả Bot API đã thiếu. Nó cũng không có REST API đọc lịch sử tin nhắn hay bảo đảm phát lại dữ liệu bị bỏ lỡ; hãy lưu sự kiện cần thiết ngay khi nhận.
Câu hỏi thường gặp
Có thể trả JSON sendMessage thay vì gọi API riêng không?
Có, với Telegram Bot API webhook và đúng định dạng phản hồi phương thức được mô tả. Nhưng không thể kiểm tra thành công hay lấy kết quả của lệnh đó.
Trả 200 OK có nghĩa là đã gửi câu trả lời không?
Không. Nó xác nhận tiếp nhận webhook. Kết quả của phương thức gửi là một kết quả riêng.
Có nên tự động gửi lại khi lần gọi API riêng bị timeout không?
Không nên gửi lại một cách máy móc. Phía từ xa có thể đã gửi xong trước khi phản hồi bị mất. Hãy lưu trạng thái chưa xác định và áp dụng quy trình đối chiếu hoặc quyết định thử lại rõ ràng.
Có thể đặt câu trả lời vào phản hồi UnifyPort webhook không?
Nội dung phản hồi bị loại bỏ. Hãy gọi POST /v1/messages riêng.
Bước tiếp theo và nguồn
Chọn cách gửi dựa trên việc bạn có cần quan sát kết quả hay không. Với tài khoản đã kết nối, hãy bắt đầu từ hợp đồng API gửi tin nhắn văn bản.
Nguồn chính thức được kiểm tra ngày 2026-09-20:
Biến tích hợp nhắn tin thành một pipeline sản phẩm ổn định.
Bắt đầu bằng cách gửi qua một API, rồi đưa mọi tin nhắn inbound trở lại hệ thống kinh doanh bằng sự kiện chuẩn.