Доступ к Google Ads API в 2026: сансет developer token, заявка через Cloud Console и brand verification

9 сентября 2026 года Google прекратил выдавать developer token для Google Ads API. Это не косметическое изменение: доступ к Google Ads API больше не привязан к токену, который вы когда-то получали через управляющий аккаунт, а определяется проектом в Google Cloud, из которого выпущены OAuth-учётные данные. Параллельно 7 октября 2026 выключается версия API v22, а для новых заявок на Basic и Standard появилась обязательная проверка бренда.

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

Как теперь устроен доступ к Google Ads API: от токена к проекту

Раньше схема была такой: вы подавали заявку из управляющего аккаунта, получали developer token, уровень доступа висел на токене, а Cloud-проект был технической деталью для OAuth. Теперь всё наоборот.

• Developer token больше не выдаётся. Существующие токены продолжают приниматься в вызовах, но стали необязательными.
• Уровень доступа определяется Cloud-проектом, из которого выпущены OAuth-учётные данные — и для пользовательской авторизации, и для сервисных аккаунтов.
• Регистрация переехала в Google Cloud Console. Новым разработчикам управляющий аккаунт Google Ads для подачи заявки больше не нужен.
• Brand verification стала обязательной для новых заявок на Basic и Standard.
• Неактивность проекта свыше 90 дней приводит к потере доступа.

Практический вывод: Cloud-проект перестал быть технической обёрткой и стал единицей учёта доступа. Кто владеет проектом — тот владеет интеграцией.

Три уровня доступа и что они значат на практике

Уровень	Для чего	Как получают	Что учесть
Test	Разработка и отладка на тестовых аккаунтах	Назначается сразу	Боевые аккаунты недоступны — только тестовая среда
Basic	Работа с боевыми аккаунтами в ограниченном объёме операций	Автоматическая проверка, решение приходит быстро	Требуется brand verification проекта
Standard	Высокий объём операций, продуктовые интеграции	Ручное рассмотрение	Готовьте описание продукта и сценариев использования

Типичная ошибка планирования — закладывать в сроки запуска только разработку и забывать про ревью. Basic проходит автоматическую проверку и обычно не держит проект. Standard рассматривается вручную, и это может занять дни. Если у вас дедлайн по запуску внутренней системы отчётности, заявку на Standard подают не в последнюю неделю.

Brand verification: что готовить

Проверка бренда привязана к Cloud-проекту и экранам согласия OAuth. Практически это значит: домен, права на него, корректно заполненный экран согласия, непротиворечивое название продукта и ссылки на политику конфиденциальности и условия использования. Разнобой между названием проекта, доменом и названием компании в документах — самая частая причина лишнего круга.

Владельцы существующего доступа от проверки освобождены, но Google рекомендует её пройти. Разумная стратегия — сделать это заранее и в спокойном режиме, а не в момент, когда понадобится повысить уровень доступа.

Как подать заявку: пошагово

Последовательность для команды, которая начинает с нуля, выглядит так. Шаги 1–4 закрывает разработчик за час, шаги 5–7 требуют участия того, кто отвечает за бренд и юридические тексты.

1. Создайте проект в Google Cloud Console. Название проекта должно совпадать с тем, как вы называете продукт вовне — это первое, что сверяют при проверке.
2. Включите Google Ads API в библиотеке API этого проекта. Распространённая ошибка — включить API в одном проекте, а учётные данные выпустить в другом.
3. Настройте экран согласия OAuth. Укажите домен, контактную почту на корпоративном домене, ссылки на политику конфиденциальности и условия использования.
4. Выпустите учётные данные — OAuth-клиент для пользовательской авторизации или сервисный аккаунт, если интеграция работает без участия человека.
5. Подайте заявку на нужный уровень доступа из этого же проекта.
6. Пройдите brand verification проекта — для новых заявок на Basic и Standard это обязательный шаг.
7. Зафиксируйте в документации, какой проект к какой интеграции относится и кто его владелец.

Самая частая причина отказа на этом маршруте — не техническая, а содержательная: из описания непонятно, что делает продукт и зачем ему доступ к рекламным данным. Пишите так, как объясняли бы клиенту: какая задача решается, чьи аккаунты обрабатываются, какие операции выполняются.

OAuth или сервисный аккаунт

Сценарий	Что выбрать	Почему
Внутренняя выгрузка отчётности по своим аккаунтам	OAuth с refresh-токеном под техническую учётку	Проще в настройке, не требует делегирования на уровне организации
Продукт, который подключает аккаунты клиентов	OAuth с явным согласием клиента	Клиент видит, какие права выдаёт, и может их отозвать
Фоновые задачи внутри своей инфраструктуры	Сервисный аккаунт	Нет привязки к живому пользователю и его паролю

Главное правило в обоих случаях одно: учётная запись, под которой выпущен refresh-токен, не должна принадлежать конкретному сотруднику. Увольнение человека не должно останавливать биддер.

Правило 90 дней: тихая потеря доступа

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

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

Сансет v22 и как вообще жить с версиями

Версии Google Ads API живут примерно год и отключаются по расписанию: v22 перестаёт работать 7 октября 2026. После отключения вызовы на старой версии не деградируют мягко — они просто перестают проходить.

Рабочая дисциплина версий выглядит так.

1. Зафиксируйте версию в одном месте. Номер версии не должен быть разбросан по десятку файлов и переменных окружения.
2. Держите дистанцию в одну версию от края. Если актуальная — v25, вы не должны сидеть на самой старой поддерживаемой.
3. Апгрейд — это задача в спринте, а не аврал. Между релизами обычно меняются имена полей и enum-значения, а не вся модель данных.
4. Читайте changelog по ресурсам, которые реально используете. Смотреть весь релиз целиком бессмысленно: вас касаются две-три сущности.
5. Проверяйте на тестовом аккаунте до переключения боевых джобов.

Свежие версии приносят не только ломающие изменения, но и полезное: например, в v25.2 появился флаг, показывающий, что целевые CPA или ROAS слишком низкие для участия поисковых кампаний в аукционах, и перцентильные бенчмарк-метрики. То есть обновление — это ещё и доступ к диагностике, которой на старой версии просто нет.

Чек-лист миграции существующей интеграции

1. Инвентаризация. Выпишите все места, где у вас вызывается API: ETL, дашборды, биддер, внутренние панели, разовые скрипты аналитиков.
2. Определите Cloud-проекты. Для каждой интеграции — из какого проекта выпущены OAuth-учётные данные. Часто выясняется, что проект заведён на личный аккаунт бывшего подрядчика.
3. Проверьте уровень доступа проекта и его соответствие реальному объёму операций.
4. Передайте владение проектом корпоративному аккаунту, если он на личном. Это самая дорогая ошибка при увольнении разработчика.
5. Проверьте версии API во всех местах из пункта 1. Всё, что на v22, переписываем до 7 октября 2026.
6. Проверьте refresh-токены и сервисные аккаунты — какие используются, когда истекают, кто их ротирует.
7. Проверьте login-customer-id в вызовах под управляющим аккаунтом: это самая частая причина отказов в правах.
8. Запустите smoke-тест на тестовом аккаунте и только потом переключайте боевые задачи.
9. Настройте алерты на ошибки авторизации, а не только на падение джоба целиком.
10. Заведите страницу владения: проект, ответственный, уровень доступа, дата последней активности.

Частые ошибки и как их читать

Симптом	Вероятная причина	Что делать
Ошибка авторизации на всех вызовах	OAuth-учётные данные выпущены из проекта без нужного уровня доступа	Сверьте проект, из которого выпущены credentials, с тем, которому одобрен доступ
Отказ в правах на конкретный аккаунт	Не передан или передан неверный login-customer-id	Укажите управляющий аккаунт, под которым выполняется запрос
Вызовы перестали проходить одномоментно	Отключение версии API	Проверьте дату сансета используемой версии
Доступ пропал после паузы в работе	Правило 90 дней неактивности	Подайте доступ заново и заведите периодический keep-alive вызов
Заявка на Basic висит	Не пройдена brand verification проекта	Приведите в порядок экран согласия, домен и реквизиты
Часть полей исчезла в ответе	Переименование или удаление поля в новой версии	Сверьтесь с changelog по конкретному ресурсу

Квоты, объёмы и проектирование нагрузки

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

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

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

А нужен ли вам API вообще

Доступ стоит усилий, и честный ответ для многих команд — «пока нет». Ориентир простой.

• До 5 аккаунтов, стандартная отчётность. Хватает интерфейса, кастомных столбцов и редактора отчётов.
• Нужны ночные проверки и реакции. Это зона автоматических правил и скриптов Google Ads.
• Нужна аналитика поверх сырых данных. Часто дешевле не писать свой коннектор, а взять выгрузку Google Ads в BigQuery.
• Десятки аккаунтов, своя логика ставок, интеграция с CRM. Вот здесь API оправдан — и тогда граница между ним и встроенной автоматизацией разобрана в материале Google Ads API вместо скриптов.

Отдельно: если вам нужно не программное управление, а быстрый ответ по конкретному аккаунту, в 2026-м появился третий путь — агент внутри кабинета. Что он умеет и где ему нужны рамки, разбираем в статье про Ask Advisor в Google Ads.

Если вы на v22 и до отключения считанные дни

Ситуация неприятная, но управляемая. Порядок действий — от самого дешёвого к самому дорогому.

1. Определите, что сломается в первую очередь. Разделите задачи на три корзины: критичные для денег (биддер, загрузка конверсий, управление бюджетами), критичные для решений (ежедневная отчётность) и всё остальное. Переносите в указанном порядке.
2. Начните с записи, а не с чтения. Остановленная отчётность — это неудобство на день. Остановленная загрузка офлайн-конверсий — это испорченное обучение стратегий ставок, и последствия растянутся на недели.
3. Посмотрите на объём реальных изменений. В большинстве интеграций между соседними версиями меняются имена нескольких полей и значения перечислений — это часы работы, а не недели. Паника обычно дороже апгрейда.
4. Временно отключите необязательное. Если какой-то отчёт собирается «потому что исторически собирался», отключите его на время миграции и освободите руки.
5. Перенесите отчётность на выгрузку. Там, где вам нужны данные, а не управление, переход на регулярную выгрузку в хранилище снимает зависимость от версий API на стороне ваших скриптов.
6. Поставьте алерты до, а не после. Отдельный алерт на ошибки авторизации и версий поможет увидеть проблему в момент сансета, а не через неделю по странным цифрам в отчёте.

Три заблуждения, которые дорого обходятся

• «У нас есть токен, значит есть доступ». Токен больше не определяет уровень доступа. Определяет проект. Проверять нужно именно проект, из которого выпущены учётные данные.
• «Старая версия ещё поработает». Отключение версии — это не деградация качества, а остановка вызовов. Плана «доживём и починим по факту» здесь не существует.
• «Доступ выдали один раз и навсегда». Правило неактивности и обязательная проверка бренда делают доступ состоянием, которое нужно поддерживать, а не разовым событием.

Безопасность: кому принадлежит ваш доступ

Перенос прав на Cloud-проект делает вопрос владения критичным. Три правила, которые стоит закрепить письменно.

1. Проект принадлежит компании, а не человеку. Владелец — корпоративный аккаунт, у разработчиков — роли, а не владение.
2. Разделите проекты по назначению. Внутренняя отчётность и клиентский продукт не должны жить в одном проекте: у них разные требования к ревью и разная цена отзыва доступа.
3. Ротация и журнал. Храните учётные данные в секрет-менеджере, ротация — по расписанию, доступ к секретам — по ролям.

Эти правила — продолжение обычной гигиены доступов в самом рекламном аккаунте: роли, корпоративная почта, современные методы входа. Подробнее — в материале про безопасность доступов Google Ads. Если вы работаете на агентских аккаунтах Google Ads, заранее согласуйте с поставщиком доступа, допустим ли программный доступ к этим кабинетам и под каким управляющим аккаунтом; это вопрос, который лучше решить до написания первой строчки кода. Полный список наших услуг — на сайте PPC Rebels.

Что это значит для агентств и подрядчиков

Для тех, кто работает с чужими аккаунтами, изменение заметнее, чем для ин-хауса. Раньше подрядчик приходил со своим токеном и подключал клиента. Теперь он приходит со своим Cloud-проектом — и это меняет разговор о собственности на интеграцию.

• Клиенту стоит знать, чей проект обслуживает его данные. Если интеграция живёт в проекте подрядчика, при расставании она уходит вместе с подрядчиком. Это не злой умысел, это архитектура.
• Агентству стоит разделять проекты по клиентам или хотя бы по продуктам. Один проект на всех означает, что проблема одного клиента с проверкой бренда становится проблемой всех.
• В договоре полезно описать сценарий выхода. Кто владеет проектом, что происходит с refresh-токенами при расторжении, в какой срок передаются доступы.

Ту же логику стоит применить к рекламным аккаунтам: право на данные и право на управление — разные вещи, и фиксировать их лучше заранее, а не в момент конфликта. Практическая сторона вопроса — в материале про управляющий аккаунт Google Ads и кросс-аккаунтные операции, где разобрано, как устроена иерархия доступов и что видно на каждом уровне.

Отдельный практический совет командам, которые только планируют интеграцию: не начинайте с биддера. Начните с чтения — выгрузки структуры и статистики в своё хранилище. Это даёт понимание модели данных, проходит на Basic и не ломает ничего в боевых кампаниях, если вы ошиблись. Управление ставками и бюджетами подключают после того, как чтение стабильно работает месяц. К этому моменту у вас уже будет понятная модель данных, рабочие алерты и опыт прохождения ревью — три вещи, без которых любая попытка сразу написать автоматическое управление ставками превращается в дорогой эксперимент на живых кампаниях.

FAQ

Мой developer token перестанет работать?

Существующие токены продолжают приниматься в вызовах, но стали необязательными: уровень доступа определяется не ими, а Cloud-проектом. Новые токены не выдаются с 9 сентября 2026.

Что делать, если я только начинаю?

Регистрируйтесь напрямую в Google Cloud Console: создайте проект, настройте экран согласия OAuth, подайте заявку на нужный уровень доступа и пройдите brand verification.

Нужен ли управляющий аккаунт Google Ads для получения доступа?

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

Чем Basic отличается от Standard?

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

Сколько ждать решения по заявке?

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

Что именно проверяет brand verification?

Соответствие проекта реальному бренду: домен и права на него, экран согласия OAuth, название продукта, политика конфиденциальности и условия использования. Расхождения между этими элементами — частая причина возврата заявки.

Что будет 7 октября 2026 с вызовами на v22?

Они перестанут проходить. Миграцию нужно завершить до этой даты, иначе любые задачи, завязанные на старую версию, остановятся.

Как часто нужно обновлять версию API?

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

Проект не использовался полгода — что теперь?

Скорее всего, доступ потерян по правилу 90 дней неактивности. Нужно восстанавливать доступ заново; чтобы ситуация не повторилась, добавьте периодический служебный вызов.

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

Технически да, но практически лучше разделять: разные клиенты означают разные требования к ревью, разную ответственность и разную цену отзыва доступа.

Нужен ли API, если у меня 3 аккаунта?

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

Сервисные аккаунты работают по новой схеме?

Да, принцип тот же: уровень доступа определяется Cloud-проектом, из которого выпущены учётные данные, независимо от того, пользовательская это авторизация или сервисный аккаунт.