Социальная интеграция начинается не с кода, а с разрешений. Вы пишете рабочий код, подключаете API, тестируете — и упираетесь в ревью, которое может затянуться на месяцы. Особенно это касается YouTube Live и TikTok Publishing.
У меня за плечами опыт создания платформы для публикации в соцсети, где мы прошли одобрение YouTube Live и TikTok. Ни один из этих процессов не был простым "отправил заявку и ждёшь". Были доработки, демонстрации, объяснения, исправление брендинга и повторные подачи. Вот что оказалось важнее всего.
Почему работающий код не спасает
HTTP-запросы — самая лёгкая часть. Вы можете успешно авторизоваться, создать трансляцию, загрузить видео, получить данные — и всё равно получить отказ.
Платформе нужно убедиться, что вы не злоупотребляете правами. Каждое разрешение OAuth должно иметь понятное назначение, а демонстрация — показать, как оно используется. Разработчик знает, зачем каждый запрос, но ревьюер видит ваше приложение впервые.
Для YouTube Live мы объясняли, зачем нужен тот или иной scope, и показывали весь сценарий: от авторизации до завершения трансляции. Без этого даже идеально работающий код не прошёл бы.
Что требует YouTube для Live
Чтобы получить доступ к YouTube Live через API, нужно интегрироваться с OAuth Google, YouTube Data API и стриминговыми функциями. В нашем случае это означало создание и управление трансляцией из приложения: создать broadcast, подключить stream, мониторить статус, показать live-информацию, завершить эфир.
Сама инфраструктура стриминга — отдельная инженерная задача. Мы использовали облачные мощности и обработку на базе FFmpeg, перейдя на изолированные задачи AWS ECS. Но это техническая часть. А вот ревью — другое.
Демонстрация — часть инженерного процесса
Ревьюер не имеет контекста, который есть у вас. Поэтому запись экрана становится обязательным артефактом. Для YouTube мы записали полный цикл:
- Подключение аккаунта YouTube.
- Отображение запрашиваемых разрешений.
- Создание трансляции.
- Запуск стриминговой инфраструктуры.
- Проверка трансляции через YouTube.
- Мониторинг эфира.
- Демонстрация live-функций приложения.
- Завершение трансляции.
Политика конфиденциальности тоже должна объяснять, как используются данные пользователя. В какой-то момент Google попросил уточнить экран согласия OAuth — чтобы было понятно, какие сервисы запрашиваются. Мы переработали этот экран, хотя функциональность не менялась.
Специфика TikTok Publishing
TikTok — другая история. Мы делали workflow, в котором видео отправляется в TikTok и попадает в черновики/inbox. Пользователь завершает публикацию уже в самом TikTok. С точки зрения архитектуры это удобно: приложение готовит контент, а TikTok остаётся финальным шагом.
Ревью в TikTok тоже оказалось многоэтапным. Мы возвращались к нему несколько раз, и каждый отказ давал новый урок.
Отказ может быть не про код
Одна из проблем была связана с иконкой приложения. Она не соответствовала брендингу. С точки зрения программиста иконка никак не влияет на OAuth-колбэк или API. Но для платформы это вопрос идентичности: пользователь должен понимать, какое приложение авторизует. Мы исправили иконку — и подали снова.
Такие мелочи могут заблокировать продакшен, хотя код давно работает.
Сравнение процессов одобрения
| Аспект | YouTube Live | TikTok Publishing |
|---|---|---|
| Объяснение разрешений | Детальное описание каждого scope | Описание в контексте приложения |
| Демонстрация | Полный цикл управления трансляцией | Показ workflow с черновиками и публикацией |
| Типичные задержки | Уточнение экрана согласия OAuth | Несоответствие брендинга |
| Количество итераций | Несколько раундов с доработкой документации | Многократные подачи, каждая — новая порция фидбека |
Чек-лист перед подачей на ревью
Чтобы не проходить этот путь наощупь, заложите в процесс следующее:
- Изучите документацию платформы и требования к разрешениям.
- Для каждого scope опишите, зачем он нужен и как используется.
- Запишите демонстрацию от первого лица: подключение аккаунта, показ разрешений, все ключевые действия.
- Приведите политику конфиденциальности в порядок — она должна прямо говорить об обработке данных.
- Проверьте иконку, название приложения и сайт — всё должно выглядеть единообразно.
- Заложите время на несколько итераций. Ревью не заканчивается одной подачей.
Типичные ошибки
Первая ошибка — считать, что код говорит сам за себя. Не говорит. Ревьюер не видит вашего кода, он видит только ваши объяснения и демонстрацию.
Вторая — показывать сырую запись без контекста. Демонстрация должна быть срежиссированной: что за чем идёт, какие разрешения видны, как функциональность связана с ними.
Третья — игнорировать требования к брендингу. Для платформы это часть безопасности и доверия пользователя.
И четвёртая — не закладывать ревью в график. Всё может растянуться на месяцы, если платформа возвращает замечания по очереди.
Вывод
Ревью API соцсетей — это не бюрократическая прихоть, а часть инженерной работы. Относитесь к нему как к отдельной задаче: готовьте демонстрации, объясняйте каждое разрешение, следите за мелочами. Тогда одобрение станет вопросом времени, а не удачи.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.