Cách một agency 2 người giám sát DM và mention trên X cho bốn khách hàng — không trả phí đọc API theo lượt — UnifyPort
Tháng 1 năm 2026, một agency truyền thông xã hội hai người tại Lisbon đang quản lý tài khoản X (Twitter) cho bốn khách hàng — hai thương hiệu thương mại điện tử, một startup SaaS và một chuỗi nhà hàng địa phương. Công việc đơn giản: giám sát DM và mention trên mỗi tài khoản, phản hồi trong vài giờ, chuyển tiếp những gì cần khách hàng xử lý trực tiếp. Công nghệ cũng đơn giản: một dịch vụ Node.js polling API X mỗi 30 giây cho từng tài khoản, kiểm tra hoạt động mới và đẩy tin nhắn vào một kênh Slack chung để phân loại.
Với bảng giá cũ của X — gói cố định hàng tháng áp dụng từ năm 2023 — hệ thống này tốn $100/tháng ở gói Basic. Dự đoán được, dễ lên ngân sách, và hoàn toàn nằm trong phí retainer mà khách hàng trả hàng tháng.
Rồi tháng Hai đến.
Đồng hồ đo bắt đầu chạy
Ngày 3 tháng 2 năm 2026, X thay thế bảng giá gói cố định bằng mô hình tính phí theo lượt. Mỗi lần gọi API — đọc hay ghi đều tính — đều có giá riêng. Không còn trần tháng. Kiến trúc polling được thiết kế cho thế giới “gọi không giới hạn trong gói” bỗng nhiên bắt đầu chạy đồng hồ đo liên tục.
Con số hiện ra ngay lập tức. Bốn tài khoản khách hàng, mỗi tài khoản polling mỗi 30 giây để kiểm tra DM và mention. 8 lần đọc mỗi phút (2 endpoint mỗi tài khoản × 4 tài khoản), 11.520 lần/ngày, khoảng 345.600 lần/tháng — chỉ riêng chi phí giám sát, chưa nhận được tin nhắn nào.
Ngày 20 tháng 4, X điều chỉnh biểu phí: đọc tài nguyên sở hữu giảm xuống $0,001/lần — chi phí đọc giám sát hàng tháng giảm còn khoảng $346. Nhưng cùng đợt điều chỉnh đó, phí ghi (phản hồi) tăng từ $0,010 lên $0,015. Agency gửi khoảng 400–600 phản hồi mỗi tháng qua bốn tài khoản; tính $0,015/lần, thêm $6–$9. Riêng con số không lớn, nhưng xu hướng đáng lo: mỗi tài khoản khách hàng mới thêm một vòng polling, mỗi phản hồi thêm đẩy hóa đơn từ cả hai phía.
Chi phí thực sự không nằm ở biểu phí — mà ở kiến trúc
Người sáng lập agency tính toán cho Q3 giả định: nếu nhận thêm hai khách hàng (hoàn toàn khả thi theo pipeline hiện tại), chỉ riêng lượt đọc polling sẽ gần như gấp đôi. Giá mỗi lần đọc đúng là thấp, nhưng khối lượng mang tính cấu trúc — quyết định bởi tần suất dịch vụ kiểm tra tin nhắn mới, không phải số tin nhắn thực sự đến. Một ngày Chủ nhật yên ắng không có DM nào, vòng polling vẫn chạy đúng tốc độ và tốn đúng bấy nhiêu như ngày ra mắt sản phẩm.
Đây là phần trong mô hình tính phí theo lượt của X mà các bài so sánh giá không nói đến: chi phí chờ tin nhắn không bằng không, và nó tăng theo kiến trúc giám sát, không theo lượng tin nhắn thực tế. Polling bốn tài khoản mỗi 30 giây có nghĩa là 345.600 lần đọc/tháng dù nhận được 10 hay 10.000 tin nhắn.
Giảm tần suất polling là giải pháp hiển nhiên nhất. Agency thử khoảng cách 2 phút trong một tuần. Thời gian phản hồi giảm rõ rệt — một DM có thể nằm im gần 4 phút trong trường hợp xấu nhất, trong khi hai khách hàng ghi rõ SLA “phản hồi trong 2 giờ” trong hợp đồng. Độ trễ không vi phạm SLA, nhưng cảm giác dịch vụ chuyển từ “gần như thời gian thực” sang “rồi sẽ thấy”. Ba ngày sau họ quay lại cài đặt cũ.
Chuyển từ pull sang push
Giải pháp đúng không phải tối ưu polling — mà là loại bỏ polling. Agency kết nối cả bốn tài khoản X của khách hàng với UnifyPort, DM và mention được đẩy tới webhook ngay khi đến. Không vòng polling, không phí đọc theo lượt, không chi phí tăng theo tần suất kiểm tra.
Thay đổi kiến trúc trông như sau:
Trước (polling):
Dịch vụ ──► X API (đọc DM) ×4 tài khoản ×2/phút = 345.600 lần đọc/tháng
Dịch vụ ──► X API (đọc mention) ×4 tài khoản ×2/phút = 345.600 lần đọc/tháng
Tổng: ~691.200 lần đọc API tính phí/tháng
Sau (webhook push):
Tài khoản X ──► UnifyPort ──► POST /webhook ──► Slack (khách A)
Tài khoản X ──► UnifyPort ──► POST /webhook ──► Slack (khách B)
Tài khoản X ──► UnifyPort ──► POST /webhook ──► Slack (khách C)
Tài khoản X ──► UnifyPort ──► POST /webhook ──► Slack (khách D)
Tổng: 0 lần đọc X APITin nhắn đến của mỗi tài khoản được gửi dưới dạng sự kiện message.received — cùng payload chuẩn hóa mà agency sẽ nhận nếu sau này kết nối thêm WhatsApp hay Zalo cho cùng những khách hàng đó:
{
"event": "message.received",
"account_id": "acct_client_a",
"provider": "twitter",
"from": "user_7d2e1f",
"text": "Hey, is the summer sale still on? Saw a post but the link was broken",
"timestamp": 1750320000,
"message_id": "x_msg_8a3b2c"
}Handler webhook xác thực mỗi lần gửi bằng HMAC-SHA256, sau đó định tuyến theo account_id đến kênh Slack tương ứng của khách hàng:
app.post("/webhook", (req, res) => {
if (!verifySignature(req)) return res.sendStatus(401);
const evt = req.body;
if (evt.event === "message.received") {
const channel = clientChannelMap[evt.account_id];
slack.postMessage(channel, {
text: `[${evt.provider}] ${evt.from}: ${evt.text}`,
metadata: { messageId: evt.message_id },
});
}
res.sendStatus(200);
});Bốn tài khoản, một endpoint, một signing secret. Dịch vụ polling tắt hoàn toàn.
Điều gì thay đổi
Chi phí X API của agency giảm từ ~$350/tháng (và tăng theo mỗi khách hàng mới) xuống không có lượt đọc tính phí. Độ trễ phản hồi thực tế còn cải thiện — sự kiện đến trong vài giây sau khi tin nhắn được gửi, thay vì chờ đến chu kỳ polling tiếp theo. Kết nối thêm tài khoản khách hàng mới không còn có nghĩa là thêm một vòng polling vào hóa đơn — chỉ là thêm một dòng trong clientChannelMap.
Đội ngũ hai người vẫn phản hồi DM và mention trên X theo cách cũ — từ Slack, qua endpoint phản hồi định tuyến ngược về UnifyPort. Điều thay đổi là “giám sát bốn tài khoản X” không còn là một khoản chi phí API cần mô hình hóa, giải thích cho khách hàng hay lo lắng về khả năng mở rộng. Nếu Q3 pipeline mang thêm hai tài khoản, webhook nhận sáu thay vì bốn. Hóa đơn không thấy sự khác biệt.
Với các agency và đội ngũ quản lý nhiều tài khoản X — đặc biệt những team có chi phí X API tăng theo tần suất polling chứ không theo lượng tin nhắn — câu hỏi kiến trúc không phải “khoảng cách polling bao nhiêu là rẻ nhất.” Mà là liệu mô hình pull có còn cần thiết khi một webhook đẩy có thể gửi cùng những tin nhắn đó mà không chạy đồng hồ đo.