← บทความทั้งหมด
บทช่วยสอน

คำขอเข้ากลุ่ม Telegram: สร้างคิวอนุมัติที่เชื่อถือได้

คิวอนุมัติคำขอเข้ากลุ่ม Telegram ที่เชื่อถือได้ไม่ควรพึ่ง push event เพียงอย่างเดียว ระบบควรดึงรายการคำขอที่รอดำเนินการเป็นระยะ ใช้ id ของแต่ละรายการเป็นตัวระบุสมาชิกสำหรับการตรวจสอบ แล้วส่งคำสั่ง approve หรือ reject อย่างชัดเจน ส่วน webhook group.join_request ช่วยให้หน้าจออัปเดตเร็วขึ้นได้ แต่สัญญาณนี้ส่งแบบ best-effort ดังนั้นรายการจาก API จึงเป็นแหล่งข้อมูลหลัก

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

  • Bot API อย่างเป็นทางการของ Telegram ส่งอัปเดต chat_join_request ได้เมื่อบอตเป็นผู้ดูแลและมีสิทธิ์ can_invite_users
  • ใน UnifyPort ให้เปิดโหมดอนุมัติด้วย group_id และ enabled: true แล้วใช้ group_id เดิมเพื่อดึงคิวที่รอดำเนินการ
  • ตอนอนุมัติหรือปฏิเสธ ให้นำ id ที่ได้จากรายการไปใส่ใน member_ids
  • ใช้ group.join_request เป็นสัญญาณที่รวดเร็ว แต่ต้องตรวจสอบสถานะจริงด้วยการดึงรายการเสมอ
  • ควรมีขั้นตอนตัดสินใจโดยคน เว้นแต่นโยบายรับสมาชิกจะแคบ ชัดเจน และตรวจสอบย้อนหลังได้

เลือกรูปแบบตัวตนก่อนเขียนคิว

หากใช้ตัวตนของบอตได้ Bot API อย่างเป็นทางการของ Telegram มี ChatJoinRequest, approveChatJoinRequest และ declineChatJoinRequest อยู่แล้ว บอตต้องเป็นผู้ดูแลกลุ่มและมีสิทธิ์ผู้ดูแล can_invite_users วิธีนี้เหมาะกับกลุ่มที่ตั้งใจให้บอตดูแลและมีขั้นตอนเฉพาะ Telegram

หากต้องตรวจสอบผ่านบัญชี Telegram ที่ใช้อยู่ หรือทีมต้องการรูปแบบการเชื่อมต่อเดียวกับช่องทางอื่น เช่น LINE สามารถใช้ UnifyPort messaging account ที่เชื่อมต่อแล้วได้ ก่อนเลือกควรอ่านความแตกต่างระหว่าง Telegram API ID, API Hash และ Bot Token

อย่าสับสนตัวตนเหล่านี้ Bot Token แทนตัวบอต ส่วน API ID และ API Hash ระบุแอปไคลเอนต์ Telegram ขณะที่ UnifyPort messaging account แทนบัญชีที่เชื่อมต่อซึ่ง API จะใช้ดำเนินการ

สร้างคิวอนุมัติคำขอเข้ากลุ่ม Telegram

1. เปิดโหมดอนุมัติการเข้ากลุ่ม

กลุ่มต้องกำหนดให้สมาชิกใหม่ผ่านการอนุมัติก่อน จึงจะมีคิวรอดำเนินการ เรียก endpoint สำหรับโหมดอนุมัติพร้อม account ID, group_id เป้าหมาย และค่า boolean enabled:

curl -X POST \
  "https://api.unifyport.ai/v1/accounts/<ACCOUNT_ID>/groups/join-approval-mode" \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "group_id": "group_example",
    "enabled": true
  }'

การดำเนินการนี้ต้องใช้สิทธิ์ผู้ดูแลกลุ่ม ควรแยกการตั้งค่านี้ออกจาก moderation worker ที่ทำงานเป็นระยะ เพราะ worker ไม่จำเป็นต้องเปลี่ยนนโยบายกลุ่มทุกครั้ง ดูสัญญาคำขอปัจจุบันได้ที่ตั้งค่าโหมดอนุมัติการเข้ากลุ่ม

2. ดึงรายการที่รอดำเนินการเป็นแหล่งข้อมูลหลัก

ส่ง group_id เป็น query parameter:

curl \
  "https://api.unifyport.ai/v1/accounts/<ACCOUNT_ID>/groups/join-requests?group_id=group_example" \
  -H "X-Api-Key: <YOUR_API_KEY>"

เก็บเฉพาะสถานะที่แอปต้องใช้ เช่น request ID, กลุ่มเป้าหมาย, สถานะการตัดสินใจ, ผู้ตรวจสอบ และเวลาภายในระบบ อย่าคาดว่า webhook ที่ตรงกันต้องมาถึงก่อนรายการจะปรากฏในผลลัพธ์

ความสัมพันธ์ของฟิลด์สำคัญนั้นตรงไปตรงมา แต่ละรายการจากดูคำขอเข้ากลุ่ม มี id และต้องนำค่านั้นไปใส่ใน member_ids ของคำขออัปเดต ห้ามใช้ชื่อที่แสดงหรือเดา Telegram ID เอง

3. กำหนดผลการตรวจสอบให้ชัดเจน

อย่างน้อยควรมีสถานะภายในสี่แบบ:

สถานะความหมายขั้นตอนถัดไป
pendingยังอยู่ในระบบต้นทางและยังไม่ตรวจสอบแสดงให้ผู้ดูแล
approvedผู้ตรวจสอบยอมรับส่ง approve
rejectedผู้ตรวจสอบปฏิเสธส่ง reject
staleไม่พบแล้วเมื่อตรวจสอบซ้ำปิดรายการโดยไม่ส่งซ้ำ

ทีมอาจใช้คำตอบจากแบบฟอร์มภายนอก allowlist หรือการตรวจสอบด้วยคนเป็นกฎของแอป แต่สิ่งเหล่านี้ไม่ใช่ฟิลด์ของ Telegram หรือ UnifyPort อย่าอนุมัติอัตโนมัติโดยดูเพียงชื่อโปรไฟล์หรือ bio ที่เชื่อถือไม่ได้

4. อนุมัติหรือปฏิเสธแบบเป็นชุด

ส่ง ID ที่ได้จากรายการตั้งแต่หนึ่งค่าขึ้นไป พร้อมกลุ่มเป้าหมายและ action ที่ชัดเจน:

curl -X POST \
  "https://api.unifyport.ai/v1/accounts/<ACCOUNT_ID>/groups/join-requests/update" \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "group_id": "group_example",
    "action": "approve",
    "member_ids": ["member_example", "member_other"]
  }'

หากปฏิเสธ ให้ใช้โครงสร้างเดิมแต่เปลี่ยนเป็น "action": "reject" endpoint นี้ต้องใช้สิทธิ์ผู้ดูแลกลุ่มเช่นกัน อ่านอนุมัติหรือปฏิเสธคำขอเข้ากลุ่ม ก่อนออกแบบการ retry หรือขนาด batch

หลังอัปเดตทุกครั้ง ให้ดึงรายการใหม่ วิธีนี้ทำให้หน้าจอภายในกลับมาตรงกับสถานะต้นทาง แม้ผู้ดูแลสองคนจะดำเนินการในเวลาใกล้กัน

5. ใช้ group.join_request เพื่อปลุก worker ไม่ใช่แทนการดึงรายการ

หากต้องการให้หน้าจอตรวจสอบรีเฟรชเร็ว ให้สมัครรับ group.join_request ที่ webhook endpoint อีเวนต์นี้บอกว่ามีคนขอเข้ากลุ่มที่เปิดการอนุมัติ แต่การส่งเป็น best-effort ขั้นตอนที่ปลอดภัยคือ:

  1. รับอีเวนต์
  2. ตรวจสอบและตอบรับ webhook
  3. เข้าคิวงานรีเฟรชสำหรับขั้นตอนตรวจสอบ
  4. เรียก endpoint รายการ
  5. สร้างหน้าจอจากรายการที่รอดำเนินการซึ่ง API ส่งกลับ

Push ช่วยลดเวลาแฝง ส่วนการตรวจสอบซ้ำช่วยคืนสถานะจริง เมื่อติดตั้ง receiver ให้อ่านแนวทาง HMAC ป้องกัน replay และการ retry ของ webhookประกอบด้วย

แยกคำขอเข้ากลุ่มออกจากการเปลี่ยนแปลงสมาชิก

คำขอเข้ากลุ่มไม่ได้แปลว่าสมาชิกเข้ากลุ่มแล้ว อย่าบันทึกผู้สมัครเป็นสมาชิกทันทีที่ได้รับ group.join_request ให้อนุมัติ ตรวจสอบรายการซ้ำ แล้วประมวลผลการเปลี่ยนแปลงสมาชิกภายหลังผ่านเส้นทางอีเวนต์ของมันเอง

ใน audit log ก็ควรแยก “ขอเข้ากลุ่ม”, “ผู้ดูแลอนุมัติ” และ “สมาชิกถูกเพิ่ม” เป็นคนละข้อเท็จจริง สำหรับเหตุการณ์หลังอนุมัติ ดูอีเวนต์เพิ่มและนำสมาชิกออกใน Telegram Communities

เช็กลิสต์ก่อนใช้งานจริง

  • ยืนยันว่าตัวตนที่เชื่อมต่อมีสิทธิ์ผู้ดูแลกลุ่ม
  • เก็บ X-Api-Key เป็น secret ฝั่งเซิร์ฟเวอร์
  • เปิดโหมดอนุมัติเป็นงานตั้งค่าของผู้ดูแลแยกต่างหาก
  • ดึงรายการที่รอดำเนินการเป็นระยะ แม้ไม่มี webhook
  • ใช้เฉพาะ request id ที่ได้จากรายการใน member_ids
  • บันทึกผู้ตรวจสอบและเหตุผลใน audit log ของระบบ
  • ดึงรายการใหม่หลังอนุมัติหรือปฏิเสธทุกครั้ง
  • ตรวจสอบลายเซ็น webhook ก่อนใช้ event เป็นสัญญาณรีเฟรช
  • อย่าถือว่า event คำขอเข้ากลุ่มเป็นหลักฐานว่าสมาชิกเปลี่ยนแล้ว

ข้อจำกัดและสิ่งที่ต้องเลือก

ใช้ Bot API อย่างเป็นทางการเมื่อบอตผู้ดูแลคือรูปแบบตัวตนที่ต้องการและขั้นตอนมีเฉพาะ Telegram เพราะมีเอกสารทางการและเมธอดอนุมัติหรือปฏิเสธโดยตรง

ใช้ unofficial interface ของ UnifyPort เมื่อจำเป็นต้องใช้ตัวตนของบัญชีเดิม หรืออยากได้รูปแบบ API ร่วมกับช่องทางอย่าง LINE ทีมยังต้องมีสิทธิ์ผู้ดูแล นโยบายตรวจสอบที่ชัดเจน การจัดเก็บ API Key อย่างปลอดภัย และขั้นตอนตรวจสอบซ้ำ อินเทอร์เฟซไม่ได้ตัดสินว่าใครควรได้รับความไว้วางใจ และการส่ง event แบบ best-effort หมายความว่าต้องคงการดึงรายการไว้

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

บอต Telegram อนุมัติคำขอเข้ากลุ่มได้หรือไม่?

ได้ Bot API อย่างเป็นทางการมีเมธอดอนุมัติและปฏิเสธ แต่บอตต้องเป็นผู้ดูแลกลุ่มและมีสิทธิ์ can_invite_users

ควรประมวลผลเฉพาะ webhook group.join_request หรือไม่?

ไม่ควร ใช้เป็นการแจ้งเตือนที่รวดเร็ว แล้วจึงดึงรายการที่รอดำเนินการ เอกสาร UnifyPort ระบุว่าสัญญาณนี้เป็น best-effort และการดึงรายการคือแหล่งข้อมูลที่เชื่อถือได้

ต้องใส่ค่าอะไรใน member_ids?

ใช้ id ของแต่ละรายการที่ endpoint รายการส่งกลับ ห้ามคำนวณจากชื่อที่แสดง

อนุมัติหลายคำขอในครั้งเดียวได้หรือไม่?

ได้ endpoint อัปเดตรับ member_ids ตั้งแต่หนึ่งค่าขึ้นไป และรับ action เป็น approve หรือ reject

หลังเรียกอนุมัติแล้วควรทำอะไร?

ดึงรายการที่รอดำเนินการใหม่ อัปเดตคิวภายใน และแยกอีเวนต์เปลี่ยนสมาชิกภายหลังออกจากคำขอเดิม

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

เริ่มจากAPI Reference สำหรับรายการคำขอเข้ากลุ่ม แล้วเพิ่ม endpoint สำหรับโหมดอนุมัติและการอัปเดตรอบวงจรตรวจสอบนี้

แหล่งข้อมูล

ตรวจสอบเมื่อ 24 สิงหาคม 2026:

UnifyPort API

เปลี่ยนการเชื่อมต่อข้อความให้เป็น pipeline ผลิตภัณฑ์ที่เสถียร

เริ่มจากการส่งผ่าน API เดียว แล้วส่งข้อความขาเข้าทั้งหมดกลับสู่ระบบธุรกิจของคุณด้วย event มาตรฐาน