ลบบัญชีรับส่งข้อความ UnifyPort: จัดการ 202 และ 204 ให้ถูกต้อง
การลบบัญชีรับส่งข้อความใน UnifyPort อาจได้ 204 No Content หรือ 202 Accepted ระบบแบบโควตาส่ง 204 เมื่อลบเสร็จ ส่วนแบบกระเป๋าเงินส่ง 202 เมื่อรับคำขอแล้ว โดยการจัดการทรัพยากรฝั่งผู้ให้บริการและการคืนเงินที่อาจมีจะดำเนินต่อแบบอะซิงโครนัส เมื่อได้ 202 ให้บันทึก operation_id แล้วตรวจสอบงานด้านการเรียกเก็บเงิน การที่บัญชีหายจากรายการไม่ได้ยืนยันว่าทุกขั้นตอนหรือการคืนเงินเสร็จแล้ว
ประเด็นสำคัญ
- ใช้การลบเมื่อเลิกใช้งานบัญชีนั้น ไม่ใช่เพื่อหยุดการเชื่อมต่อชั่วคราว
- แยกตามสถานะ HTTP ก่อนอ่าน JSON เพราะ 204 ไม่มีเนื้อหาตอบกลับ
- เก็บรหัสงานจาก 202 แยกจากรายการบัญชี
REVIEWหมายถึงยังไม่ยืนยัน ไม่ใช่หลักฐานการคืนเงิน
ตรวจสอบก่อนว่าต้องลบบัญชีจริงหรือไม่
API หยุดรันไทม์หยุดกระบวนการเชื่อมต่อโดยไม่ลบบัญชี หากต้องการหยุดเชื่อมต่อชั่วคราว ให้เลือกการควบคุมนี้ เมื่อต้องนำบัญชีที่ยังเก็บไว้กลับมาออนไลน์ ให้ใช้คู่มือกู้คืนรันไทม์ แทนการใช้การลบเป็นเครื่องมือรีสตาร์ต
หากต้องบำรุงรักษาเฉพาะ CRM หรือเวิร์กเกอร์ AI แต่ยังต้องรับข้อความ LINE ต่อไป อาจไม่จำเป็นต้องหยุดรันไทม์หรือลบบัญชีเลย บทเปรียบเทียบการบำรุงรักษา Webhookอธิบายการตรวจสอบลายเซ็นและเก็บเหตุการณ์ต่อเนื่องขณะพักการประมวลผลปลายทาง
บทความนี้กล่าวถึงทรัพยากรบัญชีใน UnifyPort ไม่ใช่การปิดบัญชี LINE, Telegram หรือ WhatsApp ของผู้ใช้โดยตรง และไม่ใช่การลบข้อมูล CRM หรือยกเลิกงานที่เวิร์กเกอร์รับไปแล้ว
อ่านผลตามข้อกำหนดการลบ
เอกสาร Delete accountกำหนด DELETE /v1/accounts/{account_id} และผลสำเร็จสองรูปแบบ:
| ผลตอบกลับ | ความหมายตามเอกสาร | สิ่งที่แอปควรทำ |
|---|---|---|
204 No Content | การลบแบบโควตาเสร็จแล้ว | ไม่อ่าน JSON และเก็บส่วนหัวเพื่อวิเคราะห์ปัญหา |
202 Accepted | รับการลบแบบกระเป๋าเงินแล้ว งานจัดการทรัพยากรและการคืนเงินที่อาจมียังดำเนินต่อ | เก็บ data.operation_id และสอบถามงานแยกต่างหาก |
| หมดเวลาหรืออ่านผลไม่ได้ | ไคลเอนต์ยังยืนยันผลไม่ได้ | คงสถานะไม่แน่นอนและตรวจสอบก่อนสั่งเปลี่ยนแปลงอีกครั้ง |
สิ่งนี้สอดคล้องกับ ความหมายของ DELETE ใน RFC 9110: การรับคำขอไม่เหมือนกับการลบที่ดำเนินการแล้วและไม่มีเนื้อหาให้ส่งกลับ อย่าแสดงทั้งสองกรณีว่า “ลบและคืนเงินครบแล้ว”
ข้อกำหนดรายการบัญชีระบุว่าบัญชีหายจากรายการเมื่อการลบแบบโควตาเสร็จ หรือเมื่อการลบแบบกระเป๋าเงินได้รับการยอมรับ ดังนั้นการมองเห็นบัญชีในรายการจึงไม่ใช่ตัวติดตามความเสร็จสิ้นของงานอะซิงโครนัส
บันทึกผลก่อนเอาแถวบัญชีออกจากหน้าจอ
ข้อแนะนำในระดับแอปคือเก็บบริบทเวิร์กสเปซที่เลือก account_id ผู้ให้บริการ การยืนยันจากผู้ดำเนินการ และเวลาส่งคำขอ ข้อมูลเหล่านี้ไม่ใช่ฟิลด์ API เพิ่มเติม หยุดสร้างงานใหม่สำหรับบัญชีนี้ในระบบของคุณ และกำหนดวิธีจัดการงานที่กำลังทำอยู่ การตั้งเงื่อนไขในแอปไม่ได้รับประกันว่าจะยกเลิกคำขอส่งข้อความที่ส่งไปแล้วได้
ตัวอย่าง Node.js นี้ลองลบเพียงครั้งเดียว ให้ส่งรหัสบัญชีที่ตรวจสอบแล้วและ API Key ฝั่งเซิร์ฟเวอร์เข้ามา โค้ดไม่มีการลองซ้ำอัตโนมัติและยังไม่ได้ทำส่วนจัดเก็บถาวร
export async function deleteMessagingAccount(accountId, apiKey) {
const response = await fetch(
`https://api.unifyport.ai/v1/accounts/${encodeURIComponent(accountId)}`,
{ method: 'DELETE', headers: { 'X-Api-Key': apiKey } }
);
const requestId = response.headers.get('X-Request-Id');
if (response.status === 204) {
return { httpStatus: 204, requestId };
}
const body = await response.json();
if (response.status === 202 && body.data?.operation_id) {
return { httpStatus: 202, requestId, operation: body.data };
}
throw new Error(`Deletion needs reconciliation; HTTP ${response.status}`);
}ชื่อ httpStatus, requestId และ operation เป็นชื่อภายในแอป ไม่ใช่ฟิลด์ตอบกลับใหม่ของ UnifyPort ให้บันทึกผลอย่างถาวรก่อนเอาแถวบัญชีออก ผู้เรียกฟังก์ชันต้องจัดการข้อผิดพลาดเครือข่าย การอ่าน JSON และผลที่ไม่คาดคิด โดยไม่เปลี่ยนเป็น “ลบเสร็จ” เงียบ ๆ เก็บรายละเอียดข้อผิดพลาดที่ปกปิดข้อมูลลับแล้วไว้ตรวจสอบ
ติดตามรหัสงาน ไม่ใช่บัญชีที่หายไป
สำหรับ 202 ให้ใช้รหัสที่บันทึกไว้กับ Get account billing operation: GET /v1/account-operations/{operation_id} โดยใช้ API Key ของเวิร์กสเปซเดียวกัน
ตัวอย่างการรับคำขอลบในเอกสารมี operation_id, kind: DELETE, state: PENDING และ account_id เอกสารสอบถามงานยังแสดง state: REVIEW คู่กับ last_error_code: cleanup_unconfirmed ด้วย REVIEW หมายถึงยังไม่ยืนยัน และไม่พิสูจน์ว่าคืนเงินแล้ว หน้าจอควรสะท้อนความไม่แน่นอนนี้แทนการแสดงผลสำเร็จ
เก็บบันทึกการตรวจสอบงานแยกต่างหาก เพื่อไม่ให้ลิงก์ติดตามหายเมื่อบัญชีถูกนำออกจากตัวเลือก กำหนดขอบเขตการสอบถามซ้ำและเงื่อนไขส่งต่อปัญหาให้ทีมดูแล บทความนี้ไม่ได้รับประกันเวลาที่จะเสร็จหรือจำนวนเงินคืน หากผลครั้งแรกสูญหายและไม่ได้เก็บรหัสงาน อย่าสร้างรหัสจาก request_id หรือสมมติว่าการอ่านรายการบัญชีจะกู้รหัสดังกล่าวได้ ให้เก็บรหัสบัญชี เวลา และข้อมูลวิเคราะห์ไว้ตรวจสอบ
สำหรับ 204 ที่ไม่มีเนื้อหา รหัสวิเคราะห์ปัญหาอยู่ในส่วนหัว X-Request-Id ดูคู่มือติดตาม Request IDเพื่อแยกการวิเคราะห์คำขอออกจากการติดตามงานธุรกิจ
การตรวจรับและคำถามที่พบบ่อย
ก่อนเปิดปุ่มลบ ให้ทดสอบว่า 204 ไม่เรียกการอ่าน JSON, รหัสงานของ 202 ยังอยู่หลังโหลดหน้าใหม่ และ REVIEW ยังคงแสดงเป็นเรื่องที่ยังไม่ยุติ เมื่อหมดเวลาควรสร้างบันทึกตรวจสอบ ไม่ใช่สร้างบัญชีใหม่อัตโนมัติหรือลบซ้ำต่อเนื่อง
หยุดรันไทม์แล้วบัญชีจะถูกลบหรือไม่?
ไม่ การหยุดรันไทม์เก็บบัญชีไว้ เอกสารวงจรชีวิตบัญชีแยกสถานะการยืนยันสิทธิ์กับสถานะการเชื่อมต่อออกจากกันเช่นกัน
202 หมายถึงลบไม่สำเร็จหรือไม่?
ไม่ใช่ หมายถึงรับการลบแบบอะซิงโครนัสในระบบกระเป๋าเงินแล้ว แต่ไม่ได้ยืนยันว่าทุกขั้นตอนที่เกี่ยวข้องเสร็จสิ้น
บัญชีหายจากรายการแปลว่าคืนเงินแล้วหรือไม่?
ไม่ บัญชีแบบกระเป๋าเงินหายจากรายการตั้งแต่รับคำขอลบ ต้องสอบถามงานด้านการเรียกเก็บเงิน อย่าอนุมานผลทางการเงินจากรายการบัญชีหรือ REVIEW
ขั้นตอนถัดไปและแหล่งอ้างอิง
ทำทั้งสองสาขาการตอบกลับตาม Delete account ก่อนเชื่อมปุ่มลบจริง ข้อมูลแอปและนโยบายเก็บรักษาต้องจัดการแยกกัน API นี้ไม่ใช่กระบวนการล้างข้อมูลทั่วไป
ตรวจสอบแหล่งข้อมูลเมื่อ 2026-10-30:
เปลี่ยนการเชื่อมต่อข้อความให้เป็น pipeline ผลิตภัณฑ์ที่เสถียร
เริ่มจากการส่งผ่าน API เดียว แล้วส่งข้อความขาเข้าทั้งหมดกลับสู่ระบบธุรกิจของคุณด้วย event มาตรฐาน