X запретил автоматические личные сообщения в 2026 году — как команды поддержки продолжают принимать и распределять входящие — UnifyPort
Если вы ведёте поддержку клиентов или работу с сообществом в X, изменения правил 2026 года наверняка прилетели вам с тревожной темой письма. Авто-DM — то самое «спасибо за подписку, посмотрите наш продукт», которое срабатывает, как только кто-то на вас подписался, — теперь прямо запрещены. Массовые DM и холодные рассылки через автоматизацию исключены. А любое программное использование эндпоинта личных сообщений в маркетинговых целях грозит полной потерей доступа к API. Добавьте сюда переход на оплату по факту использования с февраля 2026 года, где прочтение одного DM — это тарифицируемый запрос, и вывод для небольшой команды получается жёстким: исходящая автоматизация в X теперь и ограничена, и платная.
Но в панике легко упустить одну деталь. Если ваша команда использует X, чтобы принимать сообщения — вопросы по заказам, обращения в поддержку, упоминания, требующие ответа человека, — почти ни одно из ограничений 2026 года к вам не относится. Новые правила бьют по одному конкретному поведению: несогласованным, автоматизированным, массовым исходящим DM. Приём сообщений, которые люди намеренно отправляют вам, и быстрая передача их живому сотруднику — это другая задача с другим ответом.
Что именно изменилось
Стоит быть точными в формулировках, потому что заголовок («X закручивает гайки по автоматизации DM») гораздо шире самих правил.
Запрещённые действия — это по сути все формы несогласованной исходящей рассылки: авто-DM по подписке, массовые DM-кампании, холодные обращения к тем, кто вам не писал первым, и любые DM, отправленные автоматически в маркетинговых целях. X также ужесточил формулировки об обработке данных — сервисы обязаны получить явное и информированное согласие, прежде чем хранить непубличное содержимое DM, и не имеют права показывать содержимое DM тем, у кого нет на это прав.
По части цен: бесплатный тариф API закрылся для новых разработчиков в феврале 2026 года, остальных перевели на оплату по факту использования. Ставки с момента запуска менялись несколько раз, но важна сама структура: каждое чтение — это запрос, и у каждого запроса есть цена. Для команды, которая отслеживает DM опросом — каждые 30 секунд дёргает API, чтобы проверить, не пришло ли новое, — это означает счётчик, который крутится непрерывно, пришло ли за это время десять сообщений или ни одного.
Так что для входящей команды официальный путь теперь несёт две не связанные между собой статьи расходов: затраты на комплаенс (высокочастотный программный доступ попадает под проверку по правилам об автоматизации) и затраты по тарифу (каждый опрос оплачивается). И ни одна из них не имеет отношения к сообщениям, которые на самом деле присылают ваши клиенты.
Почему приём — это другая задача
Посмотрите заново на то, что на самом деле делает ваша команда поддержки. Клиент пишет вам в DM вопрос. Человек читает его, набирает ответ и отправляет. В этом исходящем сообщении нет ничего автоматического — его написал человек, — поэтому запрет на авто-DM попросту не применяется. Единственное, что действительно нужно автоматизировать, — это доставку входящего сообщения вашей команде достаточно быстро, чтобы успеть ответить в рамках SLA.
Это задача распределения входящих, а не автоматизации исходящих. И самое чистое решение — полная противоположность опросу: вместо того чтобы ваш сервис снова и снова спрашивал X «ну что, есть новое?», сообщение проталкивается вам в ту же секунду, как пришло. Нет цикла опроса — нет непрерывно крутящегося счётчика чтений и нет высокочастотного шаблона доступа, на который среагируют правила об автоматизации. Вы принимаете то, что вам прислали, человек отвечает, и вы ни разу сами не инициируете несогласованный DM.
Приём DM и упоминаний из X через один вебхук
UnifyPort подключает ваш аккаунт X и проталкивает входящие DM и упоминания на ваш собственный эндпоинт-вебхук в момент их появления. Вы регистрируете эндпоинт один раз, подписываетесь на нужные события, и входящая активность приходит как нормализованное событие message.received — той же формы, что и для WhatsApp, Telegram, LINE, TikTok и Zalo, так что мультиканальная служба поддержки читает одну схему вместо шести форматов провайдеров.
При создании вебхука вы перечисляете subscribed_events (используйте ["*"] для всего каталога или явно укажите message.received и account.status.updated) и задаёте signing_secret. После этого каждая доставка подписывается HMAC-SHA256, и ваш обработчик проверяет подпись, прежде чем довериться телу запроса. Доставленный DM выглядит так:
{
"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": "Здравствуйте — мой заказ отправлен? Ссылка на трекинг выдаёт 404",
"reply_token": "rt_9b1c7e..."
},
"timestamp": 1750939200
}
}Ваш приёмник сначала проверяет подпись, затем направляет сообщение туда, где команда разбирает обращения, — в канал Slack, в хелпдеск, в базу данных:
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);
});Обратите внимание, чего этот обработчик не делает: он никогда не отправляет DM. Он принимает, проверяет подпись и распределяет. Когда ваш сотрудник пишет ответ, тот уходит через нормализованный эндпоинт отправки UnifyPort как написанное человеком сообщение — не авто-DM и не массовая рассылка. (Одна особенность X: поле цитируемого ответа reply_to.reply_token пока поддерживается только для WhatsApp, поэтому в X вы отправляете обычный ответ, а не цитату; входящее событие всё равно несёт этот токен для платформ, которые его поддерживают.)
Поскольку события проталкиваются, а пропущенные не добираются опросом, ваша команда видит входящую активность в течение нескольких секунд после отправки сообщения — обычно быстрее, чем при 30-секундном цикле опроса, и без счётчика чтений, который крутится вхолостую в тихие дни.
Практический следующий шаг
Правила 2026 года провели чёткую границу: X не хочет, чтобы автоматические исходящие DM заваливали входящие пользователей, и теперь берёт плату за программные чтения. Входящая команда поддержки целиком находится по правильную сторону этой границы — каждый ответ пишет человек, и опрашивать API нет вообще никакой причины. Если вы сейчас гоняете опрашивающий сервис против X только ради того, чтобы узнать, когда клиент написал, переход на вебхук с push-моделью снимает и комплаенс-риск, и тарифицируемые чтения одним движением.
Подключите аккаунт X к единому входящему вебхуку, направьте его на эндпоинт, который проверяет подпись и распределяет по chat_id, и дайте команде вернуться к тому единственному, что новые правила никогда не ограничивали: отвечать людям, которые им написали.