Автопостинг в Threads через ИИ и API: очередь, n8n и защита от дублей

20 публикаций в неделю легко превращаются в кашу. Один текст уже утверждён, второй кто-то поправил после согласования, третий ушёл дважды после таймаута, а четвёртый завис между Notion и Threads.

Поэтому нормальный автопостинг начинается не с кнопки «публиковать». Сначала нужна очередь с понятными статусами. ИИ готовит и проверяет черновик. Человек утверждает смысл, факты и голос. n8n забирает только готовые записи, публикует их через официальный Threads API и записывает результат обратно.

Число «20+» здесь означает мощность процесса. Оно не обещает охват и не описывает норму Meta. Больший объём даёт больше публикаций, но результат всё равно зависит от тем, качества, реакции аудитории и состояния аккаунта. Если тебе нужна более широкая система от идей до переупаковки материалов, начни с гайда про автоматизацию контента с ИИ. Здесь разберём только технический контур публикации в Threads.

Когда собственный автопостинг оправдан

Свой workflow нужен не каждому. Если ты ведёшь один профиль и хочешь заранее поставить несколько готовых постов, проще использовать нативное расписание Threads или готовый сервис. Сравнить подходы можно в обзоре вариантов автопостинга в Threads.

Собственная связка через API имеет смысл, когда тебе нужны:

• общая очередь для автора и редактора;

• обязательное ручное утверждение;

• точные статусы от черновика до опубликованного поста;

• журнал попыток и ошибок;

• защита от повторной публикации;

• восстановление после сбоя между Threads и базой;

• несколько профилей или отдельные редакционные роли.

Такая система требует поддержки. Нужно следить за токенами, правами приложения, лимитами, сервером n8n и изменениями документации Meta. В официальной документации не указана отдельная плата за API-вызовы, но весь стек нельзя считать бесплатным. n8n Cloud или сервер, ИИ-модель, Notion и хранение медиа могут стоить денег.

Если главная проблема пока не в публикации, а в подготовке объёма, отдельно посмотри, как планировать контент без выгорания. API не исправит пустую очередь и слабые тексты.

Что официально умеет Threads API

На 10 июля 2026 года официальный Threads API поддерживает публикацию текста, изображений, видео и каруселей. Для базовой публикации приложению нужны разрешения threads_basic и threads_content_publish.

Старая инструкция про обязательную связь Threads с Instagram уже не универсальна. Changelog Meta указывает, что с 23 сентября 2025 года API доступен и профилям Threads без связанного Instagram. Для отдельных метрик подписчиков ограничения могут сохраняться.

Есть два режима доступа, которые нельзя смешивать.

Тест приложения. Ты добавляешь профиль как Threads Tester, принимаешь приглашение и проверяешь workflow на аккаунте с ролью в приложении. Так удобно собрать прототип и пройти первый сквозной тест.

Рабочий запуск для других пользователей. Если приложение будут авторизовывать люди без app role, нужные permissions должны пройти App Review, а приложение должно быть опубликовано. Работа на tester-профиле ещё не доказывает готовность публичного продукта.

У API есть технический потолок: 250 публикаций через API на профиль за скользящие 24 часа. Карусель считается одной публикацией. Это quota, а не совет по частоте. Политика Meta против спама отдельно запрещает очень высокочастотную ручную или автоматическую активность. Ограничения возможны и на меньшем объёме, если посты повторяются или поведение выглядит неаутентично.

Другие текущие ограничения:

• текстовый пост содержит до 500 символов;

• карусель включает от 2 до 20 изображений или видео;

• в посте допускается не более 5 ссылок, иначе API возвращает ошибку лимита ссылок;

• изображения: JPEG или PNG, до 8 МБ;

• видео: MOV или MP4, до 5 минут и до 1 ГБ;

• Meta должна получить медиа по публичному URL, пока обрабатывает контейнер.

Проверяй эти цифры по документации перед запуском. Лимиты и требования к медиа меняются.

Архитектура: от идеи до подтверждённой публикации

Минимальная схема выглядит так:

Notion или другая база
→ ИИ готовит черновик и запускает проверки
→ человек утверждает смысл, факты и голос
→ очередь ждёт publish_at
→ n8n забирает готовую запись
→ Threads API создаёт container
→ система проверяет его статус
→ Threads API публикует container
→ workflow читает результат
→ база получает media ID, permalink и финальный статус

ИИ здесь помогает с черновиком, сокращением, поиском повторов, длиной и стоп-словами. Модель не должна сама ставить Approved, если команда заранее не приняла другой режим и не описала его риски. Полезные роли и ограничения моделей разобраны отдельно в материале про инструменты ИИ для регулярного блога.

За запуск по времени отвечает n8n или другой scheduler. В текущем официальном flow публикации Threads API нет документированного параметра, который хранит дату будущего выхода. Не придумывай поле вроде scheduled_publish_time. n8n должен проснуться в нужный момент и только тогда вызвать API. Если сам n8n пока незнаком, сначала прочитай, как устроены workflow в n8n.

Какие поля нужны в очереди

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

У каждой записи должны быть поля:

• content_id: постоянный UUID записи;

• text: утверждённый текст;

• media_type: TEXT, IMAGE, VIDEO или CAROUSEL;

• media_url: публичная ссылка, если есть медиа;

• status: текущее состояние;

• approved_by и approved_at: кто и когда утвердил;

• publish_at: время публикации в UTC;

• display_timezone: часовой пояс для редактора;

• content_hash: отпечаток утверждённой версии;

• threads_container_id: ID созданного контейнера;

• threads_media_id: ID опубликованного объекта;

• permalink: ссылка на публикацию;

• attempt_count: число попыток;

• last_error_code, last_error_at, next_retry_at: журнал последней ошибки и следующая разрешённая попытка;

• workflow_execution_id: запуск n8n, который взял запись;

• lease_until: срок временной блокировки.

Подробный разбор структуры базы есть в гайде про контентную базу в Notion.

Не храни в этой таблице access token, app secret и другие секреты. Для них есть credentials или secret store n8n. Экспорт workflow, логи и скриншоты тоже надо проверять перед передачей другому человеку.

State machine: статусы вместо догадок

Статусы лучше задать заранее:

Draft → AI Drafted → Needs Review → Approved → Queued → Publishing → Published

Отдельные ветки обрабатывают сбои:

Publishing → Retryable Error → Queued
Publishing → Needs Human
Publishing → Published, Sync Failed → Published

Запись попадает в Approved только после проверки человеком. Затем workflow фиксирует content_hash. Если кто-то меняет текст после утверждения, hash меняется, а запись возвращается в Needs Review. Иначе редактор одобрит одну версию, а API отправит другую.

Перед внешним запросом publisher переводит запись в Publishing и ставит lease. Повторный запуск не должен брать активную запись. Notion не даёт удобной транзакционной блокировки для нескольких параллельных publishers, поэтому на старте оставь один publisher. Для конкурентной обработки используй базу с атомарным claim.

OAuth и токены без сюрпризов

Для Threads API создают Meta app с Threads use case, настраивают Authorization Window и callback, затем запрашивают минимальные permissions.

Текущий цикл авторизации такой:

1. Пользователь подтверждает доступ и приложение получает authorization code. Код действует 1 час.

2. Код обменивается на short-lived token со сроком 1 час.

3. Short-lived token обменивается на long-lived token со сроком 60 дней.

4. До истечения long-lived token система вызывает официальный refresh endpoint и проверяет результат.

5. Отдельный health check следит за permission grant. Для публичного профиля grant действует 90 дней и может продлеваться при обновлении long-lived token. Для private profile тот же механизм не продлевает grant, поэтому нужно планировать повторную авторизацию.

Не жди первого 401, чтобы вспомнить о токене. Заведи отдельный workflow, который проверяет срок действия заранее, обновляет токен и останавливает publisher при проблеме. Если обновление не прошло, запись не должна уходить в бесконечные повторы. Система ставит очередь на паузу и передаёт человеку понятную причину.

Как собрать workflow в n8n

Раздели подготовку контента и публикацию. Один workflow может собирать черновики и отправлять их на проверку. Второй работает только с утверждённой очередью.

Для публикации собери такую цепочку.

1. Schedule Trigger

Запускай опубликованный workflow по интервалу, например раз в несколько минут. Укажи timezone явно. В данных храни UTC, а локальный часовой пояс используй только для отображения редактору.

2. Query due items

Notion node или HTTP Request выбирает записи, у которых:

status = Queued
publish_at <= now
next_retry_at <= now или пусто
threads_media_id пуст

Сортируй по publish_at и бери ограниченную пачку. Пустая выборка считается нормальным результатом. Не проси ИИ срочно придумать и опубликовать текст только потому, что очередь закончилась.

3. Claim and lock

До первого запроса к Threads переведи запись в Publishing, запиши workflow_execution_id и lease_until. Затем перечитай запись. Если её уже забрал другой запуск, останови эту ветку.

4. Preflight validation

До API проверь:

• статус и данные approval;

• совпадение content_hash;

• длину текста;

• число ссылок;

• тип, размер и доступность медиа;

• время публикации;

• здоровье токена;

• quota публикаций;

• отсутствие опубликованного content_id или такого же hash в журнале.

Сравнение нейросетей для черновиков лучше оставить отдельной задачей. Здесь достаточно выбрать модель и зафиксировать её роль. Если нужно, используй гайд о том, как выбрать нейросеть для постов.

5. Create container

Базовый запрос создаёт контейнер:

POST /USER_ID/threads

В него передаются media_type, текст и, если нужно, публичный image_url или video_url. Для карусели сначала создаются от 2 до 20 дочерних контейнеров, затем общий контейнер типа CAROUSEL.

Сразу сохрани полученный threads_container_id в очередь. Если n8n упадёт через секунду, recovery workflow сможет продолжить с этого места.

6. Check container status

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

GET /CONTAINER_ID?fields=status,error_message

Документация перечисляет состояния IN_PROGRESS, FINISHED, PUBLISHED, ERROR и EXPIRED. Пока контейнер в IN_PROGRESS, жди и проверяй снова с ограниченным интервалом. В troubleshooting Meta рекомендует polling не чаще одного раза в минуту и не дольше 5 минут. После этого отложи запись и вернись к ней позже. Контейнер истекает через 24 часа.

7. Publish

Когда контейнер готов, вызови отдельный endpoint:

POST /USER_ID/threads_publish
creation_id=CONTAINER_ID

Публикация состоит минимум из создания контейнера и отдельного publish-запроса. Для медиа между ними добавляется проверка статуса.

8. Readback and update

Сразу сохрани полученный media ID. Затем прочитай опубликованный объект и permalink либо дождись publish webhook, если он настроен. Только после подтверждения ставь Published.

Финальная запись должна содержать media ID, permalink, время подтверждения и execution ID. Ответ 200 от промежуточного шага ещё не означает, что весь локальный процесс завершён.

Идемпотентность: как не выпустить один пост дважды

Самый опасный сценарий выглядит буднично:

1. Threads принял publish-запрос.

2. n8n получил ответ.

3. Обновление Notion упало по сети.

4. Запись осталась в Publishing.

5. Следующий запуск решил, что пост не вышел, и отправил его ещё раз.

Слепой retry здесь создаёт дубль.

Защита строится из нескольких слоёв:

• постоянный content_id;

• content_hash утверждённой версии;

• lease перед внешним запросом;

• сохранение container ID до publish;

• сохранение media ID сразу после ответа;

• журнал уже опубликованных ID и хэшей;

• readback перед повторным threads_publish;

• recovery workflow для зависших записей.

Recovery workflow регулярно ищет записи в Publishing с истёкшим lease. Если есть container ID или media ID, он сначала спрашивает Threads о состоянии. Найдена публикация: чинит локальный статус и permalink. Контейнер готов, но публикации нет: продолжает с publish после всех проверок. Контейнер завершился ошибкой или истёк: классифицирует сбой и только потом решает, создавать ли новый.

Никогда не повторяй threads_publish только потому, что клиент не дождался ответа. Таймаут говорит лишь о том, что ответ не пришёл вовремя.

Как обрабатывать ошибки

Раздели ошибки по реакции.

У каждого типа ошибки должно быть ограниченное число попыток. Бесконечный retry скрывает поломку и забивает API. n8n error workflow может сохранить execution, ошибку и последний выполненный node, а затем отправить человеку короткий сигнал без секретов.

У Notion API тоже есть лимиты. Текущая документация указывает среднее ограничение 3 запроса в секунду на integration и просит обрабатывать 429, 529 и Retry-After. Не обновляй одну и ту же запись после каждого мелкого node, если данные можно записать одним запросом.

Редакционные ограничители

Технически рабочий pipeline всё равно может публиковать мусор. До запуска зафиксируй правила:

1. ИИ готовит черновик и проверки. Человек утверждает смысл, факты, голос и риск.

2. После approval текст блокируется hash. Любая правка возвращает его на review.

3. Похожие hashes и повторяющиеся формулировки останавливают batch до проверки.

4. У publisher есть лимит пачки и кнопка паузы.

5. Пустая очередь не запускает автоматическую генерацию и публикацию.

6. Ошибка авторизации или политики останавливает поток, а не уходит в бесконечный retry.

7. Секреты хранятся отдельно от базы, экспортов и логов.

8. Частоту меняют по качеству, Threads Insights и состоянию аккаунта. Quota не заменяет редакционное решение.

Для 20+ постов в неделю заранее собери сетку тем и форматов. Иначе система быстро начнёт повторять одну мысль разными словами. Автоматизация ускоряет выпуск того, что уже лежит в очереди. Она не придумывает позицию автора и не отвечает за доверие аудитории.

Тестовый запуск перед боевым режимом

Не включай сразу всю неделю. Возьми tester-профиль и три утверждённых поста: один текстовый, один с изображением, один с видео или каруселью.

Проверь по порядку:

• OAuth и token health check;

• выбор только due-записей;

• возврат изменённого после approval текста в Needs Review;

• создание и сохранение container ID;

• ожидание статуса media;

• отдельный publish-запрос;

• readback media ID и permalink;

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

• сбой обновления Notion после успешной публикации;

• восстановление записи из Publishing;

• реакцию на тестовый 401, 429 и недоступный media URL;

• правильное время при UTC и локальном timezone;

• остановку через pause switch.

После теста сравни очередь, логи n8n и профиль Threads. Для каждой записи должен существовать один финальный результат: опубликована с media ID или остановлена с понятной причиной.

FAQ

Нужен ли связанный Instagram-аккаунт?

Не всегда. С 23 сентября 2025 года Threads API поддерживает профили без связанного Instagram. Для отдельных follower metrics связь или дополнительные условия могут быть нужны, поэтому проверь changelog перед разработкой аналитики.

Threads API бесплатный?

В проверенной документации Meta отдельная плата за вызовы API не указана. Остальные части системы могут стоить денег: n8n Cloud или сервер, ИИ-провайдер, Notion, хранилище и трафик для медиа.

Можно ли передать API дату будущей публикации?

В текущем официальном Posts flow документированного поля для будущей даты нет. Расписание держит n8n или другой scheduler. Нативные функции Threads живут отдельно от этого API workflow.

Можно ли публиковать три раза в день?

Технически очередь способна на такой темп, но официальной гарантии эффективности или безопасности этой частоты нет. Смотри на качество, повторы, Threads Insights, ограничения аккаунта и spam policy. Число 250 за 24 часа описывает потолок API, а не рекомендуемый темп.

Почему нельзя отправить один POST и закончить?

Официальный базовый flow сначала создаёт container, затем публикует его отдельным запросом. Для медиа между этими шагами нужно дождаться готовности контейнера.

Что делать при 401?

Остановить publisher. Проверить срок token, refresh, permission grant и необходимость повторной авторизации. Повторы одного запроса с тем же невалидным token ничего не исправят.

Что делать при 429?

Прочитать тело ответа и Retry-After, остановить новую пачку, отложить записи и повторить позже. Не обходить ограничение дополнительными аккаунтами.

С чего начать

Создай тестовую очередь из трёх уже утверждённых постов. Прогони каждый от Queued до подтверждённого Published, затем специально сломай обновление базы после publish и проверь recovery.

Когда один и тот же пост не выходит дважды, токен обновляется предсказуемо, а каждая ошибка оставляет понятный след, можно постепенно увеличивать очередь. Именно так «20+ в неделю» превращается в управляемую мощность процесса, а не в обещание алгоритмического роста.