X cấm tin nhắn riêng tự động năm 2026 — đội hỗ trợ chỉ nhận tin vẫn tiếp nhận và điều phối thế nào — UnifyPort

Nếu bạn làm chăm sóc khách hàng hay quản lý cộng đồng trên X, thay đổi quy định năm 2026 của nền tảng hẳn đã rơi vào hộp thư của bạn kèm một dòng tiêu đề đáng lo. Auto-DM — đúng kiểu tin “cảm ơn đã theo dõi, xem thử sản phẩm của chúng tôi” tự bắn ra ngay khi có người theo dõi bạn — nay bị cấm rõ ràng. DM hàng loạt và DM tiếp cận lạnh qua tự động hóa đều không còn được phép. Và bất kỳ việc dùng endpoint tin nhắn riêng theo kiểu lập trình cho mục đích tiếp thị nào cũng có thể khiến bạn mất luôn quyền truy cập API. Chồng thêm lên đó là việc chuyển sang tính phí theo lượt dùng từ tháng 2/2026, nơi đọc một tin nhắn riêng là một request bị tính tiền, kết luận cho một đội nhỏ rất thẳng thừng: tự động hóa gửi đi trên X giờ vừa bị hạn chế vừa tốn tiền.

Nhưng có một điều dễ bị bỏ qua giữa cơn hoảng. Nếu đội của bạn dùng X để nhận tin nhắn — hỏi về đơn hàng, yêu cầu hỗ trợ, các lượt nhắc cần người trả lời — thì gần như không có quy định nào trong đợt siết 2026 nhắm vào bạn. Quy định mới nhắm vào một hành vi rất cụ thể: DM gửi đi không được mời, tự động, quy mô lớn. Còn việc nhận những tin mà người ta chủ động gửi cho bạn, rồi đưa đến tay một con người thật nhanh, là một bài toán khác với một lời giải khác.

Thực ra đã thay đổi điều gì

Nói cho chính xác về quy định mới là quan trọng, vì cái tít (“X siết tự động hóa DM”) rộng hơn nhiều so với bản thân các quy định.

Những hành vi bị cấm về bản chất đều là gửi đi không được mời: auto-DM kích hoạt khi được theo dõi, các chiến dịch DM hàng loạt, DM tiếp cận lạnh tới người chưa từng nhắn cho bạn trước, và bất kỳ DM nào được gửi tự động vì mục đích tiếp thị. X cũng siết câu chữ về xử lý dữ liệu — dịch vụ phải có sự đồng ý rõ ràng và được thông báo đầy đủ trước khi lưu trữ nội dung DM không công khai, và không được để lộ nội dung DM cho người không có quyền xem.

Về giá: bậc API miễn phí đã đóng với nhà phát triển mới từ tháng 2/2026, số còn lại chuyển sang tính phí theo lượt dùng. Mức giá đã đổi vài lần kể từ khi ra mắt, nhưng điều quan trọng là cấu trúc: mỗi lần đọc là một request, và mỗi request đều có giá. Với một đội theo dõi DM bằng cách hỏi vòng (polling) — gọi API mỗi 30 giây để xem có tin mới chưa — điều đó nghĩa là một chiếc đồng hồ đo chạy liên tục, bất kể trong khoảng đó có mười tin về hay không có tin nào.

Vậy nên với một đội chuyên nhận tin, con đường chính thức giờ gánh hai khoản chi phí chẳng liên quan đến nhau: chi phí tuân thủ (truy cập lập trình tần suất cao bị soi dưới quy định tự động hóa) và chi phí theo lượt (mỗi lần polling đều tốn tiền). Và cả hai chẳng dính dáng gì đến những tin nhắn mà khách của bạn thực sự gửi đến.

Vì sao “nhận” là một bài toán khác

Hãy nhìn lại cho rõ đội hỗ trợ của bạn thật sự làm gì. Khách gửi cho bạn một DM hỏi điều gì đó. Một con người đọc nó, gõ câu trả lời, và gửi đi. Tin nhắn gửi đi này chẳng có chút “tự động” nào — do người viết — nên lệnh cấm auto-DM đơn giản là không áp dụng. Thứ duy nhất bạn thật sự cần tự động hóa là đưa tin đến đủ nhanh vào tay đội, đủ nhanh để trả lời trong SLA.

Đó là bài toán điều phối tin đến, không phải bài toán tự động hóa gửi đi. Và lời giải sạch nhất lại đúng ngược với polling: thay vì dịch vụ của bạn hỏi đi hỏi lại X “có gì mới chưa?”, tin nhắn được đẩy đến bạn ngay khoảnh khắc nó tới. Không vòng lặp polling thì không có đồng hồ đo lượt đọc chạy liên tục, và không có mẫu truy cập tần suất cao để quy định tự động hóa để mắt. Bạn nhận những gì người ta gửi đến, người trả lời, và từ đầu đến cuối bạn không hề tự khởi tạo một DM không được mời nào.

Nhận DM và lượt nhắc của X qua một webhook

UnifyPort kết nối tài khoản X của bạn và đẩy DM cùng lượt nhắc đến vào đúng endpoint webhook của bạn ngay khi chúng xảy ra. Bạn đăng ký endpoint một lần, đăng ký các sự kiện mình quan tâm, và hoạt động đến sẽ tới dưới dạng sự kiện message.received đã chuẩn hóa — cùng một hình dạng bạn nhận được cho WhatsApp, Telegram, LINE, TikTok và Zalo. Ở Việt Nam, nơi một đội có thể vừa lo WhatsApp vừa lo Zalo cho cùng tập khách, việc cả X, WhatsApp và Zalo đổ về cùng một schema message.received nghĩa là quầy hỗ trợ đa kênh chỉ đọc một schema thay vì sáu định dạng nhà cung cấp.

Khi tạo webhook, bạn liệt kê subscribed_events (dùng ["*"] cho toàn bộ danh mục, hoặc ghi rõ message.received và account.status.updated) và đặt một signing_secret. Sau đó mỗi lần gửi đều được đóng dấu chữ ký HMAC-SHA256 để handler của bạn xác minh trước khi tin vào phần thân. Một DM được gửi tới trông như sau:

{
  "event": "message.received",
  "data": {
    "account_id": "acct_x_support",
    "provider": "twitter",
    "chat_id": "dm_8841f0",
    "sender": "user_3a91c7",
    "message": {
      "id": "x_msg_5f2a91",
      "type": "text",
      "text": "Chào shop — đơn của mình giao chưa? Link theo dõi bị lỗi 404",
      "reply_token": "rt_9b1c7e..."
    },
    "timestamp": 1750939200
  }
}

Bộ nhận của bạn xác minh chữ ký trước, rồi điều phối tin đến nơi đội phân loại — một kênh Slack, một helpdesk, một cơ sở dữ liệu:

const crypto = require("crypto");

app.post("/webhook", express.raw({ type: "application/json" }), (req, res) => {
  const signature = req.get("X-UnifyPort-Signature");
  const expected = crypto
    .createHmac("sha256", process.env.SIGNING_SECRET)
    .update(req.body)
    .digest("hex");
  if (signature !== expected) return res.sendStatus(401);

  const { event, data } = JSON.parse(req.body);
  if (event === "message.received" && data.provider === "twitter") {
    routeToTriage({
      chatId: data.chat_id,
      from: data.sender,
      text: data.message.text,
      messageId: data.message.id,
    });
  }
  res.sendStatus(200);
});

Để ý handler này không làm gì: nó không bao giờ gửi DM. Nó chỉ nhận, xác minh và điều phối. Khi nhân viên của bạn viết câu trả lời, câu trả lời đi ra qua endpoint gửi đã chuẩn hóa của UnifyPort dưới dạng tin do người viết — không phải auto-DM, không phải chiến dịch hàng loạt. (Một lưu ý riêng của X: trường trả lời trích dẫn reply_to.reply_token hiện chỉ hỗ trợ WhatsApp, nên trên X bạn gửi câu trả lời thường chứ không phải trích dẫn; sự kiện đến vẫn mang token này cho các nền tảng hỗ trợ nó.)

Vì sự kiện được đẩy đến, và sự kiện bị lỡ không được bù bằng polling, đội của bạn thấy hoạt động đến trong vòng vài giây sau khi tin được gửi — thường nhanh hơn chu kỳ polling 30 giây, và không có đồng hồ đo lượt đọc chạy không tải trong những ngày vắng khách.

Bước tiếp theo thực tế

Quy định 2026 vạch một ranh giới rõ ràng: X không muốn DM gửi đi tự động làm ngập hộp thư người dùng, và nay tính phí cho việc đọc bằng lập trình. Một đội hỗ trợ chuyên nhận tin đứng hoàn toàn ở phía đúng của ranh giới đó — mọi câu trả lời đều do người viết, và chẳng có lý do gì để polling API cả. Nếu bạn đang chạy một dịch vụ polling nhắm vào X chỉ để biết khi nào khách nhắn tới, việc chuyển sang webhook kiểu đẩy gỡ bỏ cả rủi ro tuân thủ lẫn chi phí đọc theo lượt chỉ trong một bước.

Kết nối tài khoản X vào một webhook tiếp nhận hợp nhất, trỏ nó tới một endpoint xác minh chữ ký và điều phối theo chat_id, rồi để đội của bạn quay lại làm đúng cái việc mà quy định mới chưa từng hạn chế: trả lời những người đã nhắn cho họ.