5 попыток получить одно разрешение в Threads API — и как агент научился удалять слабые посты

Задача была простой. Получить одно дополнительное разрешение в Meta Developer Console — `threads_delete_posts`. Это нужно, чтобы мой AI-агент мог удалять слабые посты в Threads автоматически. Одна галочка в настройках. Казалось бы.

Полдня спустя я обнаружил, что причиной всех проблем были два пустых необязательных поля в форме, которые блокировали её сохранение. Это 2 апреля 2026 года, и я очень наглядно вспомнил правило, которое должен был знать давно: 80% времени работы с API крупных платформ уходит не на код, а на навигацию по их консолям.

Зачем вообще нужно удаление постов

У меня несколько площадок для публикации контента о виллах и автоматизации. Один из каналов — Threads. Публикации идут регулярно, часть из них набирает хорошее вовлечение, часть — проваливается без видимой причины.

Слабые посты — проблема не только эстетическая. Они снижают общий уровень вовлечения аккаунта, потому что алгоритм Threads учитывает среднее вовлечение при распределении охвата. Пост с нулём реакций тянет статистику вниз. Если их накапливается много — алгоритм начинает показывать новые публикации меньшему числу людей.

Стратегия контент-аудита проста: через 48 часов после публикации смотрю, сколько просмотров и какой engagement. Если меньше порогового значения — удаляю. Профиль остаётся чище, алгоритм видит более стабильный уровень вовлечения.

Делать это вручную — реально, но скучно. Каждое воскресенье заходить, проверять каждый пост за неделю, удалять слабые. Именно это я хотел автоматизировать: агент сам проверяет, сам удаляет, присылает отчёт что удалил и почему.

Для удаления постов через API нужно разрешение `threads_delete_posts`. Это не стандартный набор, его нужно запросить отдельно в Meta Developer Console.

Попытка 1: встроенный генератор токенов

Meta Developer Console имеет встроенный инструмент для генерации токенов. Открываешь, выбираешь нужные разрешения, нажимаешь «Generate». Я выбрал нужные разрешения, включая `threads_delete_posts`. Нажал Generate.

Токен сгенерировался. Я декодировал его, посмотрел на список разрешений — `threads_delete_posts` там не было. Генератор тихо проигнорировал одно из запрошенных разрешений без каких-либо объяснений. Просто не включил его.

Попробовал ещё раз, специально выбрав только это одно разрешение. Тот же результат: токен без нужного разрешения.

Попытка 2: Graph API Explorer

Graph API Explorer — другой инструмент Meta для работы с API и генерации токенов. Более гибкий, позволяет выбирать разрешения вручную из полного списка.

Я открыл Explorer, нашёл раздел выбора разрешений, начал искать `threads_delete_posts`. Его не было в списке вообще. Ни в поиске, ни в категориях. Как будто такого разрешения не существует.

Проверил документацию Threads API — разрешение там описано. Проверил, правильно ли выбрано приложение в Explorer — правильно. Перезагрузил страницу. Снова поискал. Разрешения нет.

Попытка 3: OAuth напрямую

Если инструменты консоли не работают — можно реализовать OAuth-флоу напрямую. Это стандартный способ: сформировать URL авторизации с нужными разрешениями в параметрах, открыть его в браузере, пройти авторизацию, получить токен из redirect URI.

Сформировал URL с `threads_delete_posts` в scope. Открыл в браузере. Прошёл авторизацию. Получил... ошибку: redirect URI заблокирован. Приложение в Meta не авторизовало мой redirect URI.

Логично: нужно добавить redirect URI в настройки приложения в Developer Console.

Попытка 4: добавление redirect URI

Зашёл в настройки приложения в Meta Developer Console. Нашёл секцию для OAuth redirect URIs. Добавил нужный URI. Нажал Save.

Форма не сохранялась. Без сообщения об ошибке. Нажимаю Save — страница будто перезагружается, поле снова пустое. Добавленный URI не сохранился. Попробовал ещё раз. Та же история.

Подумал, что может быть проблема с форматом URI. Попробовал другой формат, более простой localhost URI для тестирования. Нажал Save. Та же реакция — вроде сохранилось, но при перезагрузке поле пустое.

Попытка 5: выяснение причины

После четвёртой попытки я сел и начал методично проверять форму. Открыл DevTools браузера, посмотрел на сетевые запросы при нажатии Save. Запрос к API отправлялся, но возвращал ошибку с кодом 400. В теле ошибки — что-то про обязательные поля.

Начал заполнять все поля в форме настроек, которые были пустыми. Нашёл два поля: «App Category» и «Privacy Policy URL». Оба были помечены как необязательные (no asterisk). Оба были пустыми.

Заполнил их: выбрал категорию приложения из выпадающего списка, вставил URL политики конфиденциальности.

Нажал Save. Форма сохранилась. Redirect URI добавился. Вернулся к OAuth-флоу, прошёл авторизацию, получил токен. Проверил разрешения — `threads_delete_posts` есть.

Сколько времени это заняло

Пять попыток. Несколько часов. На получение одного разрешения для одного приложения. Код самой функции удаления поста занял минут двадцать после получения токена.

Это не уникальный случай — это стандартный паттерн работы с API крупных платформ. Meta, Google, Apple, Twitter/X — у всех Developer Console сделаны так, что документация отстаёт от реального состояния, инструменты работают непредсказуемо, форматы и требования меняются без уведомления.

Когда разработчик спрашивает «сколько времени займёт интеграция с платформой X?» — правильный ответ всегда умножать на три. Потому что треть времени уйдёт на код, а две трети — на навигацию по консолям, выяснение что не работает и почему, поиск решений в Stack Overflow и GitHub Issues.

Что за функция в итоге заработала

После получения нужного разрешения написал агента для автоматического аудита контента в Threads. Логика простая:

• Каждое воскресенье агент запрашивает список постов за последние 7 дней через Threads API
• Для каждого поста смотрит на метрики: просмотры и engagement rate (лайки + комментарии + репосты к просмотрам)
• Если просмотров меньше 50 или engagement ниже 0.5% — пост помечается как «слабый»
• Через 48 часов после публикации (не раньше — нужно дать алгоритму время) слабые посты удаляются
• Агент присылает отчёт: сколько постов удалено, какие метрики у удалённых, какие у оставшихся

Пороговые значения — 50 просмотров и 0.5% engagement — выбраны эмпирически на основе среднего уровня аккаунта. Через несколько недель посмотрю на статистику и скорректирую.

Зачем агент, а не я сам?

Технически это можно делать вручную. Зайти раз в неделю, посмотреть на посты, удалить слабые. 15-20 минут.

Но есть несколько причин, почему это лучше автоматизировать.

Первая: последовательность. Агент применяет одни и те же критерии каждый раз. Я могу пожалеть пост, в который вложил много сил, хотя он не сработал. Или удалить пост, который начал набирать вовлечение медленнее обычного, но в итоге оказался бы хорошим. Объективный порог убирает эмоциональную составляющую.

Вторая: данные. Агент не просто удаляет — он собирает данные о том, какой контент систематически проваливается. Тема, формат, время публикации, длина. Через несколько недель у меня будет статистика не по ощущениям, а по фактам.

Третья: масштаб. Сейчас один аккаунт в Threads. Потенциально — несколько. Ручной аудит масштабируется линейно: два аккаунта = в два раза больше времени. Агент обрабатывает все аккаунты за то же время.

Более широкий урок про платформенные API

История с пятью попытками и двумя пустыми полями — хороший повод поговорить про то, как устроена работа с API крупных платформ в реальности.

В теории: есть документация, есть инструменты, есть API. Интеграция = прочитал документацию + написал код.

На практике: документация устарела, инструменты ведут себя непредсказуемо, API возвращает ошибки без объяснений, и половина Stack Overflow ответов написана три года назад и уже неактуальна.

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

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

Что можно ускорить в следующий раз

Оглядываясь назад, вижу несколько вещей, которые помогли бы найти решение быстрее.

Смотреть на сетевые запросы с самого начала. DevTools показал реальную ошибку API — 400 с описанием отсутствующих обязательных полей. Если бы я открыл его на первом шаге, а не на четвёртом, нашёл бы проблему быстро.

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

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

Искать GitHub Issues проекта или Stack Overflow до того, как начать пробовать разные подходы. Часто кто-то уже столкнулся с той же проблемой и описал решение. Пять минут поиска могут сэкономить несколько часов экспериментов.