ตอบ Telegram Webhook ผ่าน response body หรือเรียก sendMessage แยกดี?

Telegram อนุญาตให้เรียกเมธอด Bot API เช่น sendMessage ภายใน HTTP response ที่ตอบกลับ webhook ได้ แต่เอกสารระบุชัดว่าแอปไม่สามารถทราบว่าคำสั่งนั้นสำเร็จหรือรับผลลัพธ์ของมันได้ หากต้องเก็บรหัสข้อความที่ส่งแล้วหรือจัดการข้อผิดพลาดจาก API ให้เรียก Bot API แยกต่างหาก การตอบ 200 OK เพื่อยืนยันรับอัปเดต ไม่ได้หมายความว่าข้อความตอบกลับในแชตถูกส่งแล้ว

ประเด็นสำคัญ

• การยืนยันรับ HTTP ผลของเมธอด API และการที่ผู้ใช้อ่านข้อความ เป็นคนละเรื่อง
• การฝังคำสั่งใน response ช่วยลดคำขอ แต่จะไม่ได้ผลลัพธ์ของเมธอด
• หากงานถัดไปต้องใช้รหัสข้อความหรือบันทึกผลการส่ง ควรเรียก sendMessage แยก
• UnifyPort ใช้สัญญาการทำงานอีกแบบ โดยทิ้ง response body ของ webhook การส่งข้อความต้องเรียก API แยก

Telegram webhook response ทำอะไรได้บ้าง

เอกสาร Telegram Bot API อธิบายว่าคุณสามารถส่งพารามิเตอร์กลับใน webhook response ด้วย application/json, application/x-www-form-urlencoded หรือ multipart/form-data และใช้ method ระบุเมธอดที่ต้องการเรียก

ตัวอย่างเชิงรูปแบบคือ JSON response ที่มี method: sendMessage พร้อม chat_id และ text ที่เหมาะสม นี่คือพารามิเตอร์สำหรับเรียกเมธอด ไม่ใช่โครงสร้าง Update ที่รับเข้ามา และไม่ได้หมายความว่าข้อความใดก็ตามใน response body จะถูกส่งเข้าแชตโดยอัตโนมัติ

FAQ ทางการ ระบุข้อแลกเปลี่ยนโดยตรง: ใช้คำขอน้อยลง แต่ไม่สามารถทราบว่าสำเร็จหรือรับผลลัพธ์ได้ ดังนั้นบันทึกว่าเซิร์ฟเวอร์ตอบ HTTP สำเร็จ จึงไม่ใช่ผลการส่งข้อความที่ขาดหายไป

บทความนี้สมมติว่าบอตรับอัปเดตได้แล้ว หากยังเลือกตัวตนหรือวิธีรับข้อมูลอยู่ ให้อ่าน Telegram Bot API webhook เทียบกับ unified inbound webhook ก่อน การเลือกระหว่าง polling กับ webhook เป็นคนละคำถามกับการเลือกวิธีตอบผู้ใช้

เปรียบเทียบการตอบใน response กับ sendMessage แยก

เรื่องที่ต้องตัดสินใจ	เรียกเมธอดใน webhook response	เรียก Bot API แยก
รูปแบบ	response body มี method และพารามิเตอร์	แอปเรียกเมธอดต่างหาก
ผลของเมธอด	แอปไม่ได้รับ	ตรวจสอบ JSON ที่ API ส่งกลับได้
รหัสข้อความที่ส่ง	ไม่ได้รับผ่านกลไกนี้	sendMessage สำเร็จแล้วคืน Message
การจัดการข้อผิดพลาด	ไม่มีผลลัพธ์ให้ใช้ตัดสินใจ	ตรวจสอบ ok, description, error_code ที่ส่งกลับมา
งานที่เหมาะ	คำตอบง่าย ๆ ที่ไม่ต้องใช้ผลการส่ง	งานที่ต้องตรวจสอบย้อนหลัง ใช้ worker หรือมีขั้นตอนต่อเนื่อง

นิยาม response และ sendMessage ทางการ ระบุว่า response มี ok ผลสำเร็จอยู่ใน result และคำขอที่ไม่สำเร็จมีข้อมูลข้อผิดพลาด ส่วน sendMessage จะคืน Message ที่ส่งแล้วเมื่อสำเร็จ

ผลสำเร็จของเมธอดยังไม่ใช่หลักฐานว่าคนอ่านแล้ว และแม้เรียก API แยก ผลก็ยังอาจไม่แน่นอนหากฝั่งปลายทางประมวลผลเสร็จ แต่ไคลเอนต์ไม่ได้รับ response

สถานการณ์สมมติ: บอตส่งคำแนะนำสั้น ๆ และไม่มีงานถัดไปต้องใช้รหัสข้อความ การตอบผ่าน response อาจเพียงพอ แต่ถ้าต้องผูกข้อความกับงานบริการลูกค้าหรือตัดสินใจตามเหตุผลที่ API ปฏิเสธ ให้เรียกแยกและเก็บผลจริง

แยกการยืนยันรับออกจากผลการส่ง

สำหรับขั้นตอนที่ใช้เวลาประมวลผลนาน แนะนำการออกแบบแอปดังนี้ ไม่ใช่การรับประกันเพิ่มเติมจาก Telegram:

1. ตรวจสอบแหล่งที่มาของ webhook และเก็บอัปเดตลงพื้นที่จัดเก็บถาวร
2. ยืนยันรับโดยไม่รอ AI, CRM หรืองานส่งข้อความ
3. ให้ worker เรียก Bot API แยก
4. บันทึกผลลัพธ์หรือข้อผิดพลาดจริงไว้กับงานในระบบ
5. มอง network timeout เป็นผลที่ยังไม่ทราบ ไม่ใช่หลักฐานว่าส่งไม่สำเร็จ

กำจัดอัปเดตซ้ำภายในขอบเขตของบอตนั้น การส่งซ้ำควรอ้างถึงงานเดิม ไม่ใช่สร้างคำตอบอีกชุด และควรกำหนดผู้รับผิดชอบการส่งเพียงจุดเดียว อย่าฝังคำตอบใน HTTP response พร้อมกับเข้าคิวให้ worker ส่งคำตอบเดียวกัน

Telegram ระบุว่าการส่ง webhook ที่ไม่สำเร็จและได้สถานะนอก 2XY จะถูกลองใหม่ นี่คือการลองส่งอัปเดตขาเข้าใหม่ ไม่ใช่สิ่งทดแทนการติดตามผลเมธอดขาออก ถ้าอัปเดตมาถึงแต่คำตอบไม่ออก ให้ตรวจบันทึกการส่งก่อนเปลี่ยนการตั้งค่า webhook คู่มือวิเคราะห์ getWebhookInfo อธิบายว่าทำไมสถานะการส่ง webhook จึงไม่ยืนยันว่างานธุรกิจเสร็จแล้ว

UnifyPort ไม่ใช้ response body เป็นคำสั่งส่งข้อความ

อินเทอร์เฟซที่ไม่เป็นทางการของ UnifyPort ไม่ใช้รูปแบบเรียกเมธอดใน response แบบ Telegram เอกสารการส่ง webhook ระบุว่า 2xx ใด ๆ ยืนยันการรับ และ response body จะถูกอ่านแล้วทิ้ง การคืน method: sendMessage จึงไม่เรียกเมธอดนั้นผ่านสัญญานี้

สำหรับบัญชีรับส่งข้อความที่เชื่อมต่อแล้ว ให้รับ message.received ตรวจสอบลายเซ็น เก็บอีเวนต์ แล้วจึงยืนยันรับ เมื่อกำหนด signing_secret การตรวจ X-Device-Signature ใช้ HMAC-SHA256 กับ X-Device-Timestamp ตามด้วยจุดและ raw request body

ส่งข้อความด้วย POST /v1/messages แยกต่างหาก โดยยืนยันตัวตนผ่าน X-Api-Key เอกสารส่งข้อความตัวอักษร นิยาม account_id, to.id, to.type, message.type และ message.text ตัวอย่าง response มี data.status: accepted ซึ่งไม่ควรถูกตีความเป็นใบตอบรับว่าอ่านแล้ว งานตอบอัตโนมัติควรตรวจ data.message.direction ด้วย เพื่อไม่ให้ข้อความขาออกของตัวเองกระตุ้นวงจรตอบซ้ำ

หากนำ LINE และ Telegram เข้า workflow เดียวกัน อย่านำความหมายของ HTTP response จากช่องทางหนึ่งไปใช้กับอีกช่องทางโดยไม่ตรวจเอกสาร ถ้าต้องการตัวตนแบบบอต ให้ใช้ Bot API ทางการต่อไป การเชื่อมบัญชีของ UnifyPort เป็นอีกการผสานระบบหนึ่ง ไม่ได้กู้ผลลัพธ์ Bot API ที่ขาดหาย และไม่มี REST API สำหรับอ่านประวัติข้อความหรือรับประกันการส่งย้อนหลัง จึงต้องเก็บอีเวนต์เมื่อมาถึง

คำถามที่พบบ่อย

คืน JSON ของ sendMessage แทนการเรียก API ได้หรือไม่?

ได้สำหรับ Telegram Bot API webhook เมื่อใช้รูปแบบ response ตามเอกสาร แต่จะตรวจสอบความสำเร็จหรือรับผลลัพธ์ของคำสั่งนั้นไม่ได้

ตอบ 200 OK หมายความว่าส่งคำตอบแล้วหรือไม่?

ไม่ใช่ เป็นการยืนยันรับ webhook ผลของเมธอดส่งข้อความเป็นอีกเรื่องหนึ่ง

ควรส่งใหม่อัตโนมัติเมื่อ API ที่เรียกแยก timeout หรือไม่?

ไม่ควรส่งซ้ำโดยไม่ตรวจสอบ ปลายทางอาจส่งแล้วแต่ response สูญหาย ให้เก็บสถานะไม่แน่นอนและตัดสินใจตามกระบวนการตรวจสอบหรือ retry ที่กำหนดไว้

ใส่คำตอบแชตใน UnifyPort webhook response ได้หรือไม่?

ระบบจะทิ้ง body ให้เรียก POST /v1/messages แยกแทน

ขั้นตอนถัดไปและแหล่งข้อมูล

เลือกวิธีตามความจำเป็นในการตรวจสอบผลการส่ง สำหรับบัญชีที่เชื่อมต่อ เริ่มจาก ข้อกำหนด API ส่งข้อความตัวอักษร

ตรวจสอบแหล่งข้อมูลทางการเมื่อ 2026-09-20:

• Telegram Bot API
• รูปแบบ response และ sendMessage ของ Telegram
• Telegram Bots FAQ