← Tất cả bài viết
Hướng dẫn

Xóa tài khoản nhắn tin UnifyPort: xử lý 202 và 204

Khi xóa tài khoản nhắn tin UnifyPort, API có thể trả về 204 No Content hoặc 202 Accepted. Chế độ hạn mức trả 204 khi xóa hoàn tất; chế độ ví trả 202 khi tiếp nhận yêu cầu, trong khi việc dọn dẹp phía nhà cung cấp và khoản hoàn tiền nếu có tiếp tục chạy bất đồng bộ. Với 202, hãy lưu operation_id rồi truy vấn tác vụ tính phí. Tài khoản biến mất khỏi danh sách hiện tại không chứng minh việc dọn dẹp hay hoàn tiền đã xong.

Điểm chính

  • Chỉ xóa khi ngừng sử dụng tài khoản, không dùng để tạm dừng kết nối.
  • Phân nhánh theo mã HTTP trước khi đọc JSON: 204 không có nội dung phản hồi.
  • Lưu mã tác vụ từ 202 độc lập với danh sách tài khoản.
  • REVIEW nghĩa là chưa xác nhận, không phải bằng chứng hoàn tiền.

Trước tiên, xác định có thật sự cần xóa tài khoản không

API dừng runtime dừng tiến trình kết nối mà không xóa tài khoản. Nếu chỉ cần tạm dừng kết nối, hãy chọn thao tác này. Khi đưa tài khoản được giữ lại trở về trạng thái trực tuyến, dùng hướng dẫn khôi phục runtime thay vì coi xóa là cách khởi động lại.

Nếu chỉ CRM hoặc worker AI cần bảo trì, bạn có thể không cần dừng kết nối hay xóa tài khoản. Bài so sánh phương án bảo trì webhook giải thích cách tiếp tục xác minh và lưu bền vững sự kiện trong khi tạm dừng khâu xử lý phía sau.

Bài này nói về tài nguyên tài khoản trong UnifyPort. Đây không phải hướng dẫn xóa danh tính gốc trên Zalo, WhatsApp hay Telegram, cũng không thay thế việc xóa dữ liệu CRM hoặc hủy công việc mà worker đã nhận.

Đọc phản hồi theo hợp đồng xóa

Tài liệu Delete account quy định DELETE /v1/accounts/{account_id} cùng hai nhánh phản hồi thành công:

Phản hồiÝ nghĩa được tài liệu xác nhậnCách ứng dụng xử lý
204 No ContentXóa trong chế độ hạn mức đã hoàn tấtKhông đọc JSON; lưu header phục vụ chẩn đoán
202 AcceptedĐã nhận yêu cầu xóa trong chế độ ví; dọn dẹp và hoàn tiền nếu có tiếp tục bất đồng bộLưu data.operation_id, truy vấn tác vụ riêng
Hết thời gian chờ hoặc không đọc được phản hồiClient chưa thể xác định kết quảGiữ trạng thái chưa rõ và đối chiếu trước khi thay đổi tiếp

Điều này phù hợp với ngữ nghĩa DELETE trong RFC 9110: tiếp nhận yêu cầu khác với việc đã thực hiện xóa và không cần trả thêm nội dung. Đừng gom cả hai thành thông báo “đã xóa và hoàn tiền toàn bộ”.

Hợp đồng danh sách tài khoản nêu rằng tài khoản biến mất sau khi xóa hoàn tất ở chế độ hạn mức, hoặc sau khi yêu cầu xóa được tiếp nhận ở chế độ ví. Vì vậy, việc còn xuất hiện trong danh sách không phải công cụ theo dõi hoàn tất tác vụ bất đồng bộ.

Lưu kết quả trước khi bỏ dòng tài khoản khỏi giao diện

Ở tầng ứng dụng, nên lưu ngữ cảnh workspace đã chọn, account_id, nhà cung cấp, xác nhận của người thao tác và thời điểm gửi yêu cầu. Đây là đề xuất thiết kế, không phải các trường API mới. Chặn tạo công việc mới cho tài khoản trong bộ lập lịch của bạn và quyết định cách xử lý công việc đang chạy. Cơ chế chặn này không bảo đảm có thể hủy yêu cầu gửi tin đã được gửi đi trước đó.

Hàm Node.js minh họa dưới đây chỉ thử xóa một lần. Truyền ID tài khoản đã kiểm tra và API Key phía máy chủ. Mã không tự thử lại và chưa triển khai lưu trữ bền vững.

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 và operation là tên do ứng dụng đặt, không phải trường phản hồi mới của UnifyPort. Lưu bền vững kết quả trước khi bỏ dòng tài khoản khỏi giao diện. Phía gọi hàm cần bắt lỗi mạng, lỗi phân tích JSON và phản hồi ngoài dự kiến; không âm thầm chuyển chúng thành “xóa hoàn tất”. Giữ chi tiết lỗi đã che dữ liệu bí mật để chẩn đoán.

Theo dõi tác vụ, không phải tài khoản đã biến mất

Với 202, dùng mã đã lưu để gọi Get account billing operation: GET /v1/account-operations/{operation_id}, bằng API Key thuộc cùng workspace.

Ví dụ tiếp nhận xóa trong tài liệu gồm operation_id, kind: DELETE, state: PENDING và account_id. Tài liệu truy vấn tác vụ cũng có state: REVIEW cùng last_error_code: cleanup_unconfirmed. REVIEW là chưa xác nhận, không chứng minh đã hoàn tiền. Giao diện cần thể hiện điều chưa rõ này thay vì đổi thành thành công.

Lưu riêng bản ghi các lần quan sát tác vụ để việc bỏ tài khoản khỏi bộ chọn không làm mất liên kết theo dõi. Đặt giới hạn thăm dò và quy tắc chuyển vấn đề cho người phụ trách. Bài viết không cam kết thời hạn hoàn tất hay số tiền hoàn. Nếu phản hồi ban đầu bị mất và chưa lưu mã tác vụ, đừng tự tạo mã từ request_id hoặc giả định đọc lại danh sách sẽ khôi phục được mã đó. Giữ ID tài khoản, thời gian và thông tin chẩn đoán để đối chiếu.

Với 204 không có nội dung, mã chẩn đoán nằm trong header X-Request-Id. Xem hướng dẫn truy vết Request ID để phân biệt chẩn đoán yêu cầu với theo dõi tác vụ nghiệp vụ.

Kiểm tra nghiệm thu và câu hỏi thường gặp

Trước khi bật nút xóa, kiểm tra rằng 204 không kích hoạt đọc JSON, mã tác vụ của 202 vẫn còn sau khi tải lại trang, và REVIEW tiếp tục hiện là chưa giải quyết. Hết thời gian chờ cần để lại hồ sơ điều tra, không tự tạo lại tài khoản hay gửi lệnh xóa liên tục.

Dừng runtime có xóa tài khoản nhắn tin không?

Không. Thao tác này giữ lại tài khoản. Tài liệu vòng đời tài khoản cũng tách trạng thái xác thực khỏi trạng thái kết nối.

202 có nghĩa là xóa thất bại không?

Không. Nó xác nhận đã tiếp nhận xóa bất đồng bộ trong chế độ ví, nhưng không chứng minh mọi bước liên quan đã hoàn tất.

Tài khoản biến mất khỏi danh sách có xác nhận hoàn tiền không?

Không. Tài khoản chế độ ví biến mất ngay khi yêu cầu xóa được tiếp nhận. Hãy truy vấn tác vụ tính phí; đừng suy ra kết quả tài chính từ danh sách hoặc REVIEW.

Bước tiếp theo và nguồn

Triển khai cả hai nhánh theo tài liệu Delete account trước khi nối với thao tác xóa trên giao diện. Dữ liệu ứng dụng và chính sách lưu giữ cần được xử lý riêng; API này không phải quy trình xóa dữ liệu tổng quát.

Nguồn được kiểm tra ngày 2026-10-30:

UnifyPort API

Biến tích hợp nhắn tin thành một pipeline sản phẩm ổn định.

Bắt đầu bằng cách gửi qua một API, rồi đưa mọi tin nhắn inbound trở lại hệ thống kinh doanh bằng sự kiện chuẩn.

Lấy API KeyXem tham chiếu API