Telegram Bot API Webhook เทียบกับ Unified Inbound Webhook: ควรรับข้อความทางไหนดี

ถ้าคุณกำลังเทียบ Telegram Bot API polling, Telegram setWebhook และ unified inbound webhook ให้เริ่มจากคำถามว่า “คุณต้องการรับข้อความในนามของตัวตนแบบไหน” Telegram Bot API รับ updates ของ bot token ไม่ได้ทำให้บัญชี Telegram ทั่วไปกลายเป็น inbox ของทีมซัพพอร์ต ถ้า bot เป็นตัวตนที่ถูกต้อง ให้ใช้ setWebhook สำหรับ HTTPS push หรือ getUpdates สำหรับ polling แต่ถ้าคุณต้องรับข้อความจากบัญชี Telegram ที่มีอยู่แล้ว หรือรวม Telegram กับ LINE, WhatsApp, TikTok, Zalo และ X ในคิวเดียว unified inbound webhook ของ UnifyPort จะตรงโจทย์กว่า โดยเฉพาะทีมไทยที่มักต้องดูแล LINE เป็นช่องทางหลักควบคู่กัน

สรุปสำคัญ

• Telegram Bot API token ใช้ยืนยันตัวตนของ bot ไม่ใช่บัญชีส่วนตัวหรือบัญชีทีม คู่มือทางการของ Telegram ระบุว่า token ได้จาก @BotFather และใช้ยืนยัน bot
• Telegram อธิบายวิธีรับ Bot API updates ไว้สองแบบ: getUpdates เป็น pull และ setWebhook เป็น push ทั้งสองแบบอยู่ในโมเดลของ bot
• UnifyPort unified inbound webhook เป็นอีกเลเยอร์หนึ่ง: เมื่อเชื่อมต่อ messaging account แล้ว คุณจะรับ event message.received แบบมีลายเซ็นใน envelope เดียวกันข้ามหลายแพลตฟอร์ม
• ถ้าคำถามของคุณใกล้กับ telegram bot api authorizing your bot token ให้อ่าน Telegram API ID และ API hash ต่างจาก Bot Token อย่างไร ก่อน แล้วค่อยกลับมาเลือกเส้นทางรับข้อความในบทความนี้
• ถ้าต้องการตัวอย่างงานจริง ดูบทความ ให้ Cursor สร้าง Telegram-to-Slack relay จาก webhook docs

Telegram Bot API รับอะไรจริง ๆ

เอกสาร Bot API ทางการของ Telegram อธิบายว่า bot แต่ละตัวมี token เฉพาะสำหรับ authorization เมื่อสร้าง bot แล้ว คุณจะได้ token และใช้ token นั้นเรียก Bot API คู่มือทางการยังอธิบายชัดเจนว่า token นี้ยืนยันตัวตนของ bot ไม่ใช่บัญชี Telegram ของคุณ

เวลาทีมค้นหา “Telegram login API” หรือ “authorizing your bot token” มักมีสามงานปนกันอยู่:

1. สร้าง Telegram bot ให้ผู้ใช้คุยกับ bot โดยตรง
2. เชื่อมต่อบัญชี Telegram ทั่วไป เพื่อรับข้อความจากแชตที่บัญชีนั้นอยู่แล้ว
3. สร้างคิวซัพพอร์ตหลายช่องทาง โดย Telegram เป็นเพียงหนึ่งช่องทางข้าง LINE, WhatsApp, Zalo, TikTok และ X

Bot API เหมาะกับงานข้อแรก แต่ไม่ใช่สถาปัตยกรรมเดียวกับข้อสองหรือสาม สำหรับงานเชื่อมต่อบัญชีทั่วไป Telegram core API ใช้ application credentials เช่น api_id และ api_hash ส่วนในเอกสาร Telegram authorization ของ UnifyPort ฟิลด์ที่เกี่ยวข้องคือ provider_data.api_id, provider_data.api_hash และสำหรับ code login จะมี provider_data.phone

Telegram Bot API webhook vs getUpdates

คู่มือ webhook ทางการของ Telegram ระบุว่าการประมวลผล bot updates ทำได้สองทาง: getUpdates และ setWebhook ความต่างหลักคือ:

ทางเลือก	รูปแบบส่งข้อมูล	เหมาะกับ	ข้อแลกเปลี่ยนหลัก
getUpdates	โค้ดของคุณ polling Telegram	prototype, bot ง่าย ๆ, traffic ต่ำ	ต้องจัดการ polling loop, offset และ response ว่าง
setWebhook	Telegram ส่ง HTTPS POST มาที่คุณ	production bot ที่มี public endpoint เสถียร	ต้องดูแล HTTPS receiver ที่เข้าถึงได้และ logic การรับส่ง
UnifyPort unified webhook	UnifyPort ส่ง event มาตรฐานแบบมีลายเซ็น	messaging account ที่มีอยู่และคิวหลายช่องทาง	คุณ integrate กับ event contract ของ UnifyPort แทน Telegram Update object

ถ้าเป็น Telegram-only bot, setWebhook มักเหมาะกับ production เพราะ Telegram จะ push updates มาที่ server ของคุณ ส่วน getUpdates เหมาะกับเครื่องมือเล็ก ๆ หรือเริ่มทดลองเร็ว ๆ แต่ทั้งสองแบบยังอยู่ในโลก Bot API: bot token, JSON update เฉพาะ Telegram และ logic เฉพาะ Telegram

เมื่อ bot ไม่ใช่ตัวตนที่ถูกต้อง

ตัวตนที่รับข้อความควรตรงกับช่องทางที่ลูกค้าใช้อยู่แล้ว ถ้าลูกค้าส่งข้อความหา Telegram account ที่รู้จักอยู่ การขอให้ย้ายไปหา bot ใหม่อาจเพิ่ม friction ให้ทีมซัพพอร์ต และในไทย LINE มักเป็นช่องทางสำคัญ ถ้าคุณออกแบบ Telegram แยกจาก LINE แล้วค่อยรวมทีหลัง ทีมจะต้องดูหลาย schema และหลาย inbox พร้อมกัน

คำถามที่ควรถามคือ: source of truth สำหรับ inbound support ควรเป็นอะไร ถ้าคำตอบคือ “event ตอนข้อความมาถึง” ก็ควรวาง signed event stream ไว้หน้าคิวและ normalize ให้เร็วที่สุด

ขอบเขตนี้เหมือนกับที่เราอธิบายไว้ใน Telegram chat automation ยังต้องมี cross-channel inbound queue แม้แพลตฟอร์มจะมี automation มากขึ้น คิวรวมก็ยังมีบทบาท

UnifyPort อยู่ตรงไหนในสถาปัตยกรรม

UnifyPort รับ event จาก provider แล้วส่งต่อเป็น webhook envelope เดียวกันไปยัง endpoint ของคุณ ดู field หลักได้ที่ Standard event types and payload ส่วน delivery headers, HMAC-SHA256 verification และ retries อยู่ใน Webhook delivery and signature verification

ตัวอย่าง Telegram inbound text message จะมี top-level shape เดียวกับ provider อื่น:

{
  "id": "evt_b1a7c3e5f8",
  "type": "message.received",
  "provider": "telegram",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-06-08T12:37:00Z",
  "data": {
    "conversation": { "id": "5005", "type": "user" },
    "sender": { "id": "4004", "type": "user", "name": "Jordan Lee" },
    "message": {
      "id": "3003",
      "direction": "inbound",
      "sent_at": "2026-06-08T12:37:00Z",
      "text": "Can you check my order?"
    },
    "event": { "kind": "message_received" }
  }
}

เมื่อเปิดใช้ signing_secret, receiver ควรตรวจ X-Device-Signature โดยใช้ raw request body ห้ามคำนวณจาก JSON ที่ serialize ใหม่ และเพราะ delivery เป็นแบบ at-least-once จึงควร deduplicate ด้วย event id หากต้องสร้าง receiver ให้ใช้ POST /v1/webhook-endpoints พร้อม public HTTPS url, subscribed_events เช่น ["message.received"] หรือ ["*"] และ signing_secret ถ้าต้องการลายเซ็น

กฎตัดสินใจสำหรับทีมเล็ก

เลือก official Bot API เมื่อ:

• ลูกค้าควรคุยกับ bot identity โดยตรง
• workflow อยู่ใน Telegram เท่านั้น
• คุณต้องการใช้ Telegram Update object เป็น model ภายใน
• คุณมี public HTTPS endpoint สำหรับ setWebhook หรือใช้ getUpdates polling ก็เพียงพอแล้ว

เลือก UnifyPort unified inbound webhook เมื่อ:

• inbox อยู่ใน Telegram account ที่มีอยู่แล้ว
• คุณต้องการรวม Telegram กับ LINE, WhatsApp, TikTok, Zalo หรือ X ใน queue เดียว
• แอปของคุณต้องประมวลผล message.received, message.updated, receipts, reactions และ account status ด้วย schema เดียว
• คุณอยากใช้ HMAC-SHA256 verification pattern เดียวแทน receiver logic แยกตาม platform

ข้อจำกัดและ trade-offs

UnifyPort ไม่ใช่ตัวแทนของทุกฟีเจอร์ใน Telegram Bot API ถ้าผลิตภัณฑ์ของคุณต้องใช้ inline keyboards, bot commands, BotFather configuration หรือความสามารถเฉพาะ bot ให้ใช้ official Bot API ต่อไป ถ้าคุณกำลังสร้าง public Telegram bot, bot token คือ credential ที่ถูกต้อง

Unified webhook เหมาะที่สุดกับ inbound intake และ routing คุณจะได้ event contract ที่เสถียร แต่ยังต้องเก็บ event, handle retries แบบ idempotent และดูแล authorization ของแต่ละ provider account ให้ถูกต้อง

FAQ

Telegram bot token เหมือนกับ Telegram API ID และ API hash ไหม?

ไม่เหมือนกัน bot token ใช้ยืนยัน bot ใน Bot API ส่วน api_id และ api_hash เป็น application credentials สำหรับ Telegram core API ถ้าประเด็นหลักคือเรื่องนี้ ให้อ่าน Telegram API ID และ API hash ต่างจาก Bot Token อย่างไร

Telegram bot ควรใช้ getUpdates หรือ setWebhook?

ใช้ getUpdates เมื่อต้องการ polling loop ที่เริ่มง่าย ใช้ setWebhook เมื่อมี HTTPS endpoint เสถียรและต้องการให้ Telegram push updates มาที่ server ทั้งคู่เป็นวิธีทางการของ Bot API สำหรับ bot

Telegram Bot API webhook รับข้อความที่ส่งมาหาบัญชี Telegram ทั่วไปได้ไหม?

ไม่ได้ Bot API webhook รับ updates ของ bot ที่ระบุด้วย bot token เท่านั้น สำหรับบัญชีทั่วไปหรือ cross-channel support queue ให้ใช้ account-level inbound path เช่น UnifyPort unified webhook

ถ้าเลือก unified webhook แล้วควรเริ่มจากอะไร?

ลงทะเบียน receiver ก่อนเชื่อมต่อ account เอกสาร Create webhook endpoint แสดง url, status, subscribed_events, signing_secret และ retry_policy.max_attempts

ขั้นตอนถัดไป

ถ้าคุณทำ Telegram bot อย่างเดียว ให้เริ่มจาก Telegram Bot API docs ถ้าคุณทำ support หรือ automation queue ให้เริ่มจาก UnifyPort webhook events reference สร้าง message.received handler หนึ่งตัว แล้วค่อยเพิ่ม LINE หรือ channel อื่น ๆ

แหล่งข้อมูลที่ตรวจสอบเมื่อ 2026-08-28

• Telegram Bot API: https://core.telegram.org/bots/api
• Telegram Bot tutorial: https://core.telegram.org/bots/tutorial
• Telegram webhook guide: https://core.telegram.org/bots/webhooks
• Telegram application credentials: https://core.telegram.org/api/obtaining_api_id