Пересмотр тарифов X API в 2026 году: что значит плата за использование для получения DM и упоминаний — UnifyPort

Если вы регистрировались в X API впервые в этом году, то столкнулись со стеной, которой не было в 2025-м: бесплатного уровня больше нет. В феврале 2026 года X перевёл API для разработчиков на модель платы за использование, заменив фиксированные планы (от $0 до $5 000 в месяц в зависимости от уровня). Новым разработчикам теперь нужно пополнить баланс ещё до первого вызова — варианта «попробовать бесплатно пару раз» не осталось.

Для команд, которым нужно лишь получать прямые сообщения и упоминания на аккаунте X — то есть только входящий поток, а не публикации или аналитика — это полностью меняет суть решения. Раньше вопрос был «какой фиксированный план покрывает наш объём», теперь — «сколько стоит каждое полученное сообщение, и эта статья расходов будет повторяться постоянно».

Что изменилось — и изменилось дважды

Реформа февраля 2026 года задала базовые правила: оплата за каждый вызов, чтения и записи тарифицируются раздельно, лимитов по объёму нет — платите за то, что вызываете. Затем 20 апреля 2026 года X выпустил внеплановое обновление тарифов. Чтение собственных данных аккаунта — своих публикаций, подписчиков и DM — резко подешевело до $0,001 за ресурс, что в 5 раз ниже первоначальной цены. При этом стандартные запросы на запись выросли с $0,010 до $0,015 за запрос.

Для конвейера входящих DM и упоминаний это означает два одновременно работающих счётчика:

• Чтение входящих DM и упоминаний — после апрельской корректировки относительно дёшево, $0,001 за чтение собственного ресурса
• Отправка ответов — это запрос на запись, теперь $0,015 за вызов

Цифра $0,001 кажется незначительной, пока не пересчитать её на повседневную работу команды поддержки. Небольшая команда, обрабатывающая несколько сотен входящих DM и упоминаний в день, на каждое сообщение, требующее ответа, платит и за чтение, и за запись — и это без учёта накладных расходов на поллинг, поскольку «получение» DM через API X всё ещё фактически означает периодический опрос на наличие новой активности, а не push-уведомления через webhook. Частота поллинга умножает стоимость чтения независимо от того, сколько реальных сообщений приходит.

При небольшом объёме всё это не катастрофично — как отмечали ещё в начале года, при лёгком использовании речь идёт о паре долларов в месяц. Но это совершенно другая модель затрат по сравнению с «платим фиксированную сумму в месяц и больше не думаем об этом». Любой всплеск сообщений от клиентов — запуск продукта, внезапно популярное упоминание, накопившиеся обращения в поддержку — теперь напрямую отражается в счёте, в пересчёте на сообщения, ответы и опросы.

Переосмысление: получение сообщения не должно требовать вызова API

Легко упустить вот что: описанная структура затрат — это свойство официального API X, а не свойство самого факта «получить сообщение в X». Если ваша реальная задача — «когда кто-то пишет в DM или упоминает наш аккаунт, бэкенд должен сразу узнать об этом и иметь возможность ответить» — эта задача сама по себе не обязывает платить X за каждое чтение и каждую запись.

Именно этот разрыв закрывает неофициальный входящий интерфейс UnifyPort для X. Вместо того чтобы бэкенд опрашивал API X (и платил за каждое чтение), UnifyPort подключается к аккаунту X напрямую и передаёт входящие события на ваш webhook по мере их появления — без подсчёта чтений, без цикла опроса, без платы за каждое сообщение со стороны платформы.

Как это выглядит на практике

Подключение аккаунта X к UnifyPort использует тот же сессионный поток, что описан для расширения UnifyPort Exporter: вы создаёте запись аккаунта с provider: "twitter" и auth_mode: "session", экспортируете сессию уже авторизованного аккаунта и запускаете runtime.

POST /v1/accounts
Content-Type: application/json

{
  "provider": "twitter",
  "auth_mode": "session"
}

После этого каждое DM и упоминание, поступающее на этот аккаунт, приходит на ваш webhook как событие message.received — в том же нормализованном формате, который UnifyPort использует для WhatsApp, Telegram, LINE, TikTok и Zalo:

{
  "event": "message.received",
  "account_id": "acct_8Q2vK",
  "provider": "twitter",
  "from": "user_3f9c1a",
  "text": "Hey, do you ship to the EU?",
  "timestamp": 1749427200,
  "message_id": "x_msg_7c1f9d"
}

Ответ отправляется тем же вызовом POST /v1/messages, адресованным через account_id и from — точно так же, как для любого другого канала. Нет отдельного шага «прочитать» DM перед обработкой — событие уже содержит всё необходимое, и нет никакой тарификации по объёму сообщений или частоте опроса.

X (Twitter) ──► UnifyPort ──► message.received ──► ваш webhook
                    ▲                                    │
                    │                                    ▼
              POST /v1/messages ◄──────────── ваша логика ответа

Каждая доставка подписывается HMAC-SHA256 с использованием настроенного вами signing_secret, поэтому проверка подписи — это один и тот же код для всех каналов.

Что это значит на практике

Если ваше использование X действительно небольшое — несколько DM в неделю, без другой автоматизации — новая ставка чтения $0,001 после апрельской корректировки достаточно дешева, и официального API будет достаточно. Разворачивать отдельное подключение не имеет смысла.

Но если X — один из нескольких каналов, которые ваша команда отслеживает для входящих сообщений, и особенно если объём непредсказуем — вирусный пост, всплеск обращений в поддержку, запуск продукта — модель оплаты за чтение и запись превращает «нас стало больше замечать» напрямую в «счёт стал больше», а это неправильное направление для такого стимула. Подключение X через единый webhook UnifyPort переводит его на ту же унифицированную, нетарифицируемую основу, что и остальные ваши каналы — одно событие message.received, одна точка для ответов, без дополнительного уровня тарификации.