เปิดหรือปิดการอนุมัติเข้ากลุ่ม WhatsApp ผ่าน API

หากต้องการเปิดหรือปิดการอนุมัติเข้ากลุ่ม WhatsApp ผ่าน UnifyPort ให้ส่ง POST /v1/accounts/{account_id}/groups/join-approval-mode พร้อม group_id และค่าบูลีน enabled ซึ่งเป็นฟิลด์ที่ต้องระบุ ใช้ true เพื่อกำหนดให้ต้องอนุมัติ และ false เพื่อปิดข้อกำหนดนี้ การเรียกนี้เปลี่ยนการตั้งค่ากลุ่ม ไม่ใช่การอนุมัติหรือปฏิเสธคำขอที่รออยู่ทั้งหมด

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

• การเปลี่ยนการตั้งค่าต้องเป็นการตัดสินใจของผู้ดูแล ไม่ใช่ผลข้างเคียงจากการเปิดหน้าคิวคำขอ
• ส่งค่าบูลีนของ JSON ไม่ใช่สตริง "false" หรือค่าจากช่องทำเครื่องหมายที่หายไป
• ปัจจุบันการดำเนินการนี้รองรับ whatsapp ไม่ใช่ whatsapp-protocol ซึ่งเป็นผู้ให้บริการแยกต่างหาก และไม่ครอบคลุม LINE หรือช่องทางอื่น
• แยกค่าที่ต้องการ ผลตอบกลับจาก API และผลการตรวจสอบภายหลังออกจากกัน

แยกการตั้งค่าออกจากการพิจารณาคำขอ

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

สิ่งที่ผู้ดูแลต้องการ	การดำเนินการที่เหมาะสม
ให้ผู้เข้าร่วมใหม่ต้องได้รับอนุมัติ	ตั้ง enabled: true
ปิดข้อกำหนดการอนุมัติ	ตั้ง enabled: false
อนุมัติหรือปฏิเสธผู้สมัครที่เลือก	ใช้การอัปเดตคำขอเข้ากลุ่มแยกต่างหาก
อ่าน URL สำหรับเชิญ	ใช้การอ่านลิงก์เชิญ

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

สร้างฟอร์มเปิดและปิดที่ชัดเจน

เอกสารโหมดอนุมัติเข้ากลุ่ม กำหนดให้ส่ง group_id และค่าบูลีน enabled โดยตารางการรองรับของแต่ละช่องทาง ระบุว่าการดำเนินการนี้รองรับเฉพาะ WhatsApp UnifyPort ใช้ อินเทอร์เฟซที่ไม่เป็นทางการ สำหรับบัญชีรับส่งข้อความที่เชื่อมต่ออยู่ ไม่ใช่คำขอ WhatsApp Cloud API

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

พฤติกรรมของฟอร์มที่แนะนำ:

1. แสดงบัญชีและกลุ่มที่เลือกในหน้าจอยืนยัน
2. ให้เลือกอย่างชัดเจนว่าจะเปิดหรือปิดการอนุมัติ
3. หากไม่ทราบค่าปัจจุบัน ให้แสดงว่าไม่ทราบ อย่าแปลงข้อมูลที่ขาดเป็นสถานะปิด
4. ส่งคำขอเมื่อยืนยันเท่านั้น ไม่เขียนค่าตอนโหลดหน้าหรือรีเฟรชคิว
5. รักษาค่า false ไว้ระหว่างตรวจสอบและแปลงเป็น JSON การตรวจแบบ truthiness อาจทำให้ค่าปิดหายไป

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

ส่งการเปลี่ยนแปลงที่ยืนยันแล้วหนึ่งครั้ง

JavaScript ฝั่งเซิร์ฟเวอร์ต่อไปนี้ใช้ฟิลด์คำขอจริง เป็นตัวอย่างที่ยังไม่ได้รันทดสอบในงานนี้ และไม่มีการลองใหม่อัตโนมัติ:

export async function setJoinApproval({ apiKey, accountId, groupId, enabled }) {
  if (!apiKey || !accountId || !groupId || typeof enabled !== 'boolean') {
    throw new Error('Account, group, credential and boolean choice required');
  }

  const response = await fetch(
    `https://api.unifyport.ai/v1/accounts/${encodeURIComponent(accountId)}/groups/join-approval-mode`,
    {
      method: 'POST',
      headers: { 'X-Api-Key': apiKey, 'Content-Type': 'application/json' },
      body: JSON.stringify({ group_id: groupId, enabled })
    }
  );
  const requestId = response.headers.get('X-Request-Id');
  const body = await response.json();
  return { httpStatus: response.status, requestId, body };
}

เก็บ API key ไว้ที่ backend ชื่อ httpStatus, requestId และ body ที่ฟังก์ชันคืนเป็นชื่อภายในแอป ไม่ใช่ฟิลด์ API ใหม่ เอกสารระบุผลสำเร็จเป็น 200 OK พร้อม data.ok: true ให้บันทึกค่าบูลีนที่ต้องการและผลลัพธ์ก่อนแสดงว่าสำเร็จ ผู้เรียกต้องจัดการข้อผิดพลาดเครือข่ายและการอ่าน JSON หากไม่ได้รับคำตอบ ให้คงสถานะผลลัพธ์ไม่แน่นอนแทนการแสดงว่าปิดแล้ว

จัดลำดับการเปลี่ยนแปลงสำหรับบัญชีและกลุ่มเดียวกันภายในแอป หากผู้ดูแลคนหนึ่งสั่งเปิดและอีกคนสั่งปิดภายหลัง การลองส่งคำขอเก่าซ้ำอาจนำค่าที่ล้าสมัยกลับมา การล็อกหรือการตรวจ revision ในแอปเป็นมาตรการของคุณ ไม่ใช่ความสามารถ conditional write ของ API ต้นทาง ผู้ดูแลยังเปลี่ยนค่าผ่านแอป WhatsApp ได้อย่างอิสระ

ตรวจการตั้งค่าแยกจากคำขอที่รออยู่

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

หลังเปิด ให้ผู้ดูแลตรวจค่าจริงและทดสอบคำเชิญในสภาพแวดล้อมที่ควบคุมก่อนแจกจ่ายลิงก์วงกว้าง ขั้นตอนพิจารณาคำขอยังคงต้อง poll รายการคำขอเข้ากลุ่ม เพราะเอกสารระบุว่าสัญญาณ push เป็นแบบ best-effort

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

หากคำขอตั้งค่าหมดเวลา ให้เก็บค่าที่ต้องการและข้อมูลวินิจฉัย ตรวจค่าภายใน WhatsApp แล้วขอการตัดสินใจใหม่ก่อนส่งซ้ำ อย่าส่งค่าตรงข้ามโดยอัตโนมัติเพื่อย้อนการเปลี่ยนแปลง เพราะผู้ดูแลอีกคนอาจเปลี่ยนนโยบายไปแล้ว

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

ละ enabled เพื่อคงค่าเดิมได้ไหม?

ไม่ได้ การดำเนินการนี้ต้องมีค่าบูลีน หากไม่ต้องการเปลี่ยนก็ไม่ต้องเรียก

enabled=false จะปฏิเสธทุกคนที่รออยู่หรือไม่?

เอกสารไม่ได้ระบุเช่นนั้น ให้แยกการปิดการตั้งค่ากับการจัดการคำขอเดิมเป็นคนละงาน

worker ควรเปิดการอนุมัติทุกครั้งที่ poll หรือไม่?

ไม่ควร การ poll คือการอ่าน ส่วนการเปลี่ยนนโยบายคือการเขียนโดยผู้ดูแล การแยกสองงานช่วยป้องกัน worker ยกเลิกการตัดสินใจของผู้ดูแล

ใช้กับ Telegram หรือ LINE ได้ไหม?

ไม่ได้ตามตารางการรองรับปัจจุบันของ UnifyPort รูปแบบ route ที่เหมือนกันไม่ได้ยืนยันว่าทุกช่องทางรองรับ

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

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

ตรวจสอบแหล่งข้อมูลเมื่อ 2026-11-02:

• Meta: การจัดการกลุ่ม WhatsApp
• UnifyPort: ตั้งค่าโหมดอนุมัติเข้ากลุ่ม
• UnifyPort: การรองรับการดำเนินการของช่องทาง
• UnifyPort: รายการคำขอเข้ากลุ่ม