Дисклеймер для товарища майора, админов, модераторов и всех неравнодушных к западным платформам.

Данный материал преследует исключительно просветительские цели. Он не является призывом нарушать правила площадок, обходить законы, заниматься спамом, массовой автоматизацией или чем-то еще, за что потом придется грустно объясняться.

Meta Platforms Inc. признана экстремистской организацией и запрещена в РФ. X/Twitter остается зарубежной социальной сетью со своими правилами, фильтрами и антибот-системами.

Воспринимайте текст как разбор инженерной кухни и карту подводных камней: как устроена публикация, где ломается автоматика, какие ошибки прилетают и почему "просто отправить POST-запрос" в реальности быстро превращается в отдельную маленькую драму.

Мне хотелось простой вещи: написать текст один раз и отправить его сразу в несколько соцсетей.

Без ручного копирования.
Без "открыл вкладку, вставил, нажал отправить".
Без ощущения, что я работаю SMM-стажером у самого себя.

С Threads* все оказалось неожиданно спокойно. У Meta* есть нормальный API, понятная схема публикации, токен, user id, два запроса - и пост улетает.

А вот с X* все быстро превратилось в отдельный квест.

Официальный API у X* сейчас живет по модели pay-per-use: покупаешь кредиты, тратишь их на запросы, следишь за балансом. Для большого продукта это нормально. Для маленькой автоматизации "я хочу отправлять пару постов в день" - уже не так весело.

Поэтому я пошел другим путем: сделал отправку через веб-сессию, примерно так же, как это делает сам браузер.

Спойлер: работает.
Второй спойлер: не всегда.
Третий спойлер: если ответ 200, это еще не значит, что пост опубликован.

Архитектура без героизма

Схема получилась простая:

мой сервер
-> Cloudflare Worker
  -> Threads* API
   -> X web endpoint

Почему через Worker?

Во-первых, не хочется хранить токены соцсетей на основном сервере.

Во-вторых, мой сервер находится в России. По понятным причинам напрямую ходить с него в X* - так себе план: где-то запросы отваливаются, где-то все упирается в сетевые ограничения, а иногда ты просто не понимаешь, это у тебя код сломался или маршрут до Twitter опять решил умереть.

Cloudflare Worker в этой схеме стал маленьким внешним шлюзом. Основной сервер делает запрос не в X*, а в мой Worker. А уже Worker, находясь снаружи этой сетевой каши, ходит в Threads* и X*.

В-третьих, Worker удобно использовать как тонкий прокси: сервер отправляет только текст и общий секрет, а вся авторизация до соцсетей живет отдельно.

В-четвертых, если одна соцсеть начинает капризничать, не нужно переписывать весь проект.

Для Threads* путь выглядит цивилизованно:

1. Создать контейнер поста.

2. Подождать пару секунд.

3. Опубликовать контейнер.

4. Получить post_id.

Примерно так:

const containerRes = await fetch(
  `https://graph.threads.net/v1.0/${userId}/threads?access_token=${token}`,
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      media_type: "TEXT",
      text
    })
  }
);

const container = await containerRes.json();

const publishRes = await fetch(
  `https://graph.threads.net/v1.0/${userId}/threads_publish?access_token=${token}`,
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      creation_id: container.id
    })
  }
);

На этом месте можно было остановиться.

Но мне же нужен был еще X*.

Официальный API X*: все правильно, но не бесплатно

У X* есть официальный API v2. Он умеет публиковать посты через POST /2/tweets, отдает нормальные rate-limit headers и в целом ведет себя как API.

Проблема в том, что это больше не бесплатная игрушка для pet-проектов. В документации X* сейчас указана pay-per-use модель: покупаешь кредиты, запросы списываются по мере использования.

Для бизнеса - окей.

Для эксперимента - хочется сначала обойтись без кассы.

И тут появляется второй путь: не официальный API, а веб-интерфейс.

Когда вы публикуете пост в браузере, X* тоже куда-то отправляет запрос. Это не публичный REST API, а внутренний GraphQL endpoint. Если повторить запрос браузера с актуальной сессией, CSRF-токеном и похожим набором заголовков, пост может создаться.

Ключевое слово - "может".

Это не контракт. Это наблюдение за тем, как сегодня работает сайт.

Как достать токены из браузера

Чтобы браузерный путь вообще завелся, нужны два значения из вашей авторизованной сессии X:

auth_token 
ct0 

auth_token - это cookie авторизации.

ct0 - CSRF-токен. Его нужно передавать и как cookie, и как заголовок x-csrf-token.

Важно: это не "API-ключи" в нормальном смысле. Это куски вашей браузерной сессии. Если кто-то получит эти значения, он фактически сможет действовать от имени вашего аккаунта. Поэтому хранить их нужно как пароль: в secrets, env-переменных или хранилище Cloudflare Worker, но не в git.

Самый простой способ достать их руками:

1. Открываем https://x.com в браузере, где вы уже залогинены.

2. Открываем DevTools.

3. Идем в Application -> Storage -> Cookies -> https://x.com.

4. В таблице cookies находим auth_token.

5. Там же находим ct0.

6. Копируем значения в secrets.

В Chrome это выглядит примерно так:

DevTools 
 -> Application
  -> Cookies
    -> https://x.com
      -> auth_token
      -> ct0 

В Firefox путь похожий:

DevTools   
 -> Storage     
  -> Cookies       
   -> https://x.com

После этого в Worker можно положить их в переменные окружения:

wrangler secret put TWITTER_AUTH_TOKEN
wrangler secret put TWITTER_CT0

А в запросе к X* использовать так:

headers: {
  "authorization": "Bearer <PUBLIC_X_WEB_BEARER>",
  "content-type": "application/json",
  "x-csrf-token": env.TWITTER_CT0,
  "x-twitter-active-user": "yes",
  "x-twitter-auth-type": "OAuth2Session",
  "x-twitter-client-language": "ru",
  "cookie": `auth_token=${env.TWITTER_AUTH_TOKEN}; ct0=${env.TWITTER_CT0};`,
  "referer": "https://x.com/home"
}

Bearer здесь выглядит страшно, поэтому в примере я оставил плейсхолдер. Это не ваш личный auth_token, а web bearer, который можно увидеть в браузерном запросе самого X*. Личная часть - именно auth_token и ct0.

Есть второй способ: открыть DevTools -> Network, руками отправить тестовый пост, найти запрос CreateTweet и посмотреть:

• URL GraphQL-запроса;

• queryId;

• headers;

• payload;

• набор features.

Это даже полезнее, потому что X* периодически меняет внутренний GraphQL-запрос. Если ваш старый Worker внезапно перестал публиковать, первым делом нужно сравнить его запрос с новым браузерным CreateTweet.

Минимальный чеклист после копирования токенов:

auth_token есть в Cookie
ct0 есть в Cookie
x-csrf-token равен ct0
x-twitter-auth-type = OAuth2Session
referer указывает на https://x.com/home
payload похож на свежий браузерный CreateTweet

Если auth_token протух, X* обычно начинает отвечать ошибками авторизации.

Если ct0 не совпадает с cookie, запрос может падать даже при живом auth_token.

Если GraphQL queryId или features устарели, можно получить странные ошибки, включая пустой tweet_results.

Отдельный момент про "протухание" токенов. Я ожидал, что браузерная сессия X* начнет отваливаться каждые пару дней, но на практике за две недели auth_token и ct0 не протухли и продолжали работать.

Это не значит, что они вечные.

Скорее всего, они живут как обычная веб-сессия: пока вы не вышли из аккаунта, не сменили пароль, не сбросили активные сессии и X* не решил, что активность подозрительная. Поэтому я бы не закладывался на конкретный срок жизни токенов. Лучше сделать так, чтобы ошибка авторизации была видна сразу, а обновление токенов занимало две минуты через DevTools.

Почему браузерный путь не похож на нормальный API

У официального API все скучно и понятно:

201 Created -> пост создан
429 Too Many Requests -> уперлись в лимит
401 Unauthorized -> проблема с токеном

У веб-GraphQL все веселее.

Я проверяю не только HTTP-статус, а наличие реального id поста:

const tweetId =
  data?.data?.create_tweet?.tweet_results?.result?.rest_id;

if (!tweetId) {
  return {
    success: false,
    error: "GraphQL ответил, но пост не создан",
    detail: data
  };
}

Потому что X* может вернуть успешный HTTP-ответ, но внутри будет пусто:

{
  "data": {
    "create_tweet": {
      "tweet_results": {}
    }
  }
}

Формально запрос обработан.
Фактически поста нет.

Это один из самых неприятных типов ошибок, потому что если проверять только response.ok, можно радостно записать в лог "опубликовано", хотя в профиле ничего не появилось.

Две недели логов: что реально происходит

Проект крутился на сервере с 17.04.2026 по 05.05.2026.

После дедупликации соседних дублей в логах получилось:

X success:                27
X errors:                 42
no rest_id:               13
daily limit, code 344:    18
automated request, 226:    5
too long, code 186:        6

То есть это не ситуация "один раз настроил и забыл".

X* отказывал четырьмя разными способами.

Ошибка 1: no rest_id

Самый тихий отказ.

HTTP может быть успешным, GraphQL-ответ есть, но rest_id нет. Для меня это значит только одно: пост не создан.

Причины могут быть разные:

• текст похож на дубль;

• контент выглядит подозрительно;

• endpoint поменял поведение;

• сессия вроде живая, но уже не совсем;

• X* просто решил не объяснять.

Именно поэтому в такой автоматизации нельзя писать:

if (response.ok) success = true;

Нужно проверять бизнес-результат: появился ли id поста.

Ошибка 2: daily limit, код 344

Вот тут X* уже говорит прямо:

Authorization: You have reached your daily limit for sending Tweets and messages.
Please try again later. (344)

Интересный момент: речь не шла о тысячах постов в день. Расписание было человеческое: несколько запусков в сутки.

Но X* считает не только ваш скрипт в вакууме. На лимиты могут влиять:

• посты через веб;

• посты через мобильное приложение;

• повторы;

• сообщения;

• действия аккаунта;

• внутренняя репутация сессии;

• предыдущие неудачные попытки.

Поэтому "я отправляю всего 3 поста в день" не гарантирует, что X не скажет "на сегодня хватит".

Ошибка 3: automated request, код 226

Самая честная ошибка:

Authorization: This request looks like it might be automated.
To protect our users from spam and other malicious activity,
we can't complete this action right now. Please try again later. (226)

Это уже не rate limit. Это антибот.

И здесь важно понимать: если вы используете неофициальный браузерный путь, вы играете на территории, где правила не документированы.

Могут влиять:

• слишком одинаковые заголовки;

• странный fingerprint;

• публикации по расписанию минута в минуту;

• повторяющаяся структура текста;

• отсутствие нормальной активности аккаунта;

• подозрительный IP;

• устаревший GraphQL-запрос;

• неактуальные browser headers.

Случайные задержки перед публикацией немного помогают против слишком механического поведения, но не превращают серую схему в официальный API.

Ошибка 4: Tweet needs to be a bit shorter, код 186

Вот тут я сам сначала чуть не попался.

В логе ошибка выглядит так:

Authorization: Tweet needs to be a bit shorter. (186) 

На первый взгляд кажется, что 186 - это лимит символов. Типа X* внезапно разрешает не 280, а 186 знаков.

Нет. 186 - это код ошибки.

Я достал из логов тексты, на которых это падало. Их обычная длина была почти под потолком:

275
278
277
277
277
278

То есть формально они были меньше 280 символов.

Но X* считает длину не так, как len(text) в Python. У него есть weighted length: emoji, некоторые символы, ссылки и отдельные сущности могут съедать больше места, чем кажется в обычном счетчике.

Поэтому правило "режем до 280" оказалось недостаточно надежным.

Лучше держать запас:

MAX_X_CHARS = 250 

Да, вы теряете 30 символов.

Зато не ловите ситуацию, где текст выглядит нормальным, проходит ваш локальный лимитер, а X* отвечает "сделай покороче".

Что пришлось сделать, чтобы оно хотя бы жило

Первое: разнести формат под разные соцсети.

Threads спокойно принимает длиннее. X* живет в коротком формате, поэтому один и тот же текст нельзя просто отправлять в обе стороны.

Для X* нужен отдельный форматтер:

короткий заголовок
1-2 хэштега максимум
главная мысль
без длинного вступления
запас по длине

Второе: не считать HTTP 200 успехом.

Успех для X* - это только наличие id поста.

Третье: логировать тело ошибки целиком.

Без этого невозможно понять, что произошло: лимит, антибот, слишком длинный текст, пустой GraphQL или сломанный запрос.

Четвертое: закладывать fallback.

Если Threads* опубликовался, а X* отказал - это не причина валить весь процесс. Лучше сохранить ошибку, отправить уведомление и попробовать позже.

Пятое: не делать вид, что это стабильная интеграция.

Официальный API - это контракт.

Веб-GraphQL - это наблюдение за тем, как сегодня работает сайт.

Сегодня работает. Завтра поменяли GraphQL query id, набор features или проверку заголовков - и все.

Что бы я делал для продакшена

Если это клиентский проект или бизнес-процесс, я бы использовал официальный X* API и просто заложил стоимость в бюджет.

Если это личный инструмент, внутренний кросспостинг или pet-проект, браузерный путь может быть нормальным компромиссом. Но только если честно принять его ограничения:

• он может сломаться без предупреждения;

• он может нарушать правила платформы;

• он не дает нормальных гарантий;

• его нужно мониторить;

• успех нужно проверять по id поста, а не по HTTP-статусу;

• тексты нужно резать с запасом, а не ровно под 280.

Итог

Автоматизировать отправку в Threads* легко: Meta* дает понятный API, предсказуемую схему и нормальные ошибки.

С X* сложнее.

Официальный API есть, но он платный. Неофициальный путь через веб-сессию работает, но ведет себя не как API, а как браузер, за которым постоянно смотрит антиспам.

За две недели у меня получилось 27 успешных публикаций в X* и 42 отказа после дедупликации логов. Главный вывод простой: проблема не в одном лимите. Там одновременно живут дневные ограничения, антибот-фильтр, тихие GraphQL-отказы без созданного поста и отдельная ловушка с длиной текста.

Поэтому если вы хотите автоматизировать кросспостинг, не начинайте с вопроса "как отправить запрос".

Начните с другого:

1. как я пойму, что пост реально опубликован?

2. что я сделаю, если X* ответил 200, но поста нет?

3. где я увижу ошибку через неделю?

4. готов ли я чинить это после очередного обновления фронтенда?

5. какой запас по длине я оставляю под счетчик X*?

Потому что отправить запрос - легко.

Сделать так, чтобы оно жило больше двух дней, - вот там начинается инженерия.

Надеюсь нигде звездочки не пропустил?