AdAce AdsAPI-ключі AdAce Ads: області доступу, термін дії, перевірка та відкликання
API-ключ AdAce Ads автентифікує підтримуваний MCP-клієнт або REST-інтеграцію без потреби інтерактивного входу для кожного запиту. Це облікові дані, а не токен Google чи Meta. Створюйте ключ лише для конкретної інтеграції та простору, починайте з мінімальної області доступу й перевіряйте, що саме може читати інтеграція.
Що авторизує ключ
Ключ прив’язаний до свого простору та користувача. Його фактичні дозволи є перетином областей доступу ключа й поточної ролі користувача, а доступ до клієнтів перевіряється застосунком. Тому зміна ролі може зменшити можливості наявного ключа. Копіювання ідентифікатора простору в запит не надає доступу до цього простору. Використовуйте read для звітів; ключ не може самостійно надати доступ до непризначеного клієнта або відключеного акаунта провайдера.
Повне значення ak_prefix_secret відображається лише один раз під час створення, тоді як AdAce Ads зберігає лише хеш для перевірки. Відображений префікс ідентифікує ключ, не розкриваючи його повне значення. Збережіть повні дані у схваленій конфігурації секретів інтеграції-одержувача. Не додавайте їх до звичайних повідомлень у чаті ШІ, URL-адрес, вихідного коду, скриншотів чи журналів налагодження. Втрачене збережене значення неможливо відновити з префікса: створіть заміну та відкличте втрачений ключ.
Через REST ключі дозволяють читання, а з областю propose — створення пропозицій змін; вони не дають прямого дозволу на погодження, виконання або зміну налаштувань. Проте пропозиція не є повністю пасивною: налаштована автополітика клієнта може просувати відповідну пропозицію в межах чинних дозволів і лімітів. MCP також застосовує перевірку областей доступу та ролей для своїх інструментів. Використовуйте read для тестового звітування замість припущення, що propose гарантує ручний перегляд кожної наступної дії.
Наприклад, створіть ключ із рівнем read та назвою «Тижневий звіт North Store» із терміном дії, що відповідає періоду перевірки. Налаштуйте підтримуваний клієнт на надсилання його як облікових даних Authorization Bearer до задокументованого ендпойнта. Викличте get_started через MCP, а потім прочитайте список акаунтів дозволеного клієнта. Порівняйте один знайомий акаунт із даними в застосунку. Це підтверджує коректний шлях читання без створення пропозицій чи внесення змін у рекламу.
Облікові дані з чітким власником і призначенням
- Надавайте кожній надійній інтеграції зрозумілі облікові дані, щоб під час подальшої перевірки доступу було чітко видно власника та призначення.
- Обмежуйте доступ за допомогою областей, поточних дозволів користувача та прив’язки до простору замість спільного використання пароля агенції або токена провайдера.
- За потреби оновлюйте облікові дані окремої інтеграції та перевіряйте нові перед видаленням застарілих під час планової ротації.
Створення, перевірка та ротація
- Відкрийте «Підключити ШІ» → «API-ключі» у потрібному просторі. Перегляньте наявні назви, кількість активних ключів і час останнього використання, перш ніж створювати нові облікові дані.
- Створіть ключ із власною назвою та доступом read для першої перевірки. За потреби виберіть термін дії та пройдіть двофакторну автентифікацію, якщо цього вимагає застосунок.
- Збережіть одноразове значення безпосередньо в конфігурації секретів надійної інтеграції. У своєму обліку доступів залишайте лише його назву, префікс, власника, призначення та термін дії.
- Використайте інтеграцію для дозволеного читання даних. Перевірте як повернуті дані, так і відповідну активність або підтвердження останнього використання; час останнього використання ключа оновлюється не частіше ніж раз на хвилину.
- Для планової ротації створіть і перевірте новий ключ, перемкніть інтеграцію та відкличте старий. Якщо ключ скомпрометовано, негайно відкличте його та дослідіть активність перед налаштуванням заміни.
Ліміти, помилки та скомпрометовані облікові дані
- Ліміт створення: реалізація дозволяє мати п’ять активних ключів на особу в просторі. Прострочені або відкликані ключі більше не займають активний слот. Переглядайте застарілі інтеграції замість спільного використання ключа, щоб не перевищувати ліміт.
- 401 або відхилені облікові дані: перевірте ендпойнт, заголовок Bearer, повне значення, термін дії та відкликання. 403: перевірте простір, фактичну область доступу, поточну роль і призначення клієнта. Область ключа read не варто розширювати лише тому, що запит на зміну налаштувань чи пропозиції було відхилено.
- Відповідь про обмеження частоти запитів вимагає очікування відповідно до Retry-After і зменшення повторних викликів; це не означає, що ключ було відкликано. Відкликання ключа блокує подальшу автентифікацію, але не видаляє попередні звіти та не скасовує зміни. Локальні тести перевіряють правила реалізації, а не приймання інтеграції в продакшені чи публічну платну доступність.
Джерела й додаткові матеріали
Спробуйте на своїх кабінетах
Створіть робочий простір, підключіть Google або Meta в кілька кліків і побачте свої кабінети чітко. Зміни проходять погодження або дозволяються налаштованою вами політикою.
Створити простір