Що таке API-ключ: навіщо він потрібен і як зберігати безпечно

Коротка відповідь

API-ключ — це довгий випадковий рядок символів, який діє як пароль не для людини, а для програми: він доводить сервісу, що саме ваш воркфлоу (у n8n, Zapier, Make чи будь-де ще) має право звертатись до його API. Ключ вставляється один раз у налаштування підключення, і кожен наступний запит воркфлоу автоматично несе цей ключ як доказ авторизації.

Як це працює на практиці

Ви реєструєтесь у сервісі (платіжна система, погодний API, CRM)
У панелі керування сервісом (зазвичай розділ "Розробникам"/"API"/"Інтеграції") генеруєте ключ
Вставляєте цей ключ у поле підключення в no-code інструменті (Zapier — поле "Connect", Make — модуль підключення, n8n — Credential)
З цього моменту кожен запит воркфлоу автоматично несе ключ, і сервіс перевіряє його перед виконанням дії

Якщо ключ відсутній, неправильний чи відкликаний — сервіс відхиляє запит. Саме це причина помилки 401 Unauthorized, яку можна побачити в n8n, Zapier чи Make, коли ключ перестав працювати — той самий код помилки, до речі, виникає й коли не проходить перевірка вебхука: в обох випадках запит прийшов без дійсного доказу авторизації.

API-ключ проти входу через OAuth — у чому різниця

Обидва способи дозволяють no-code інструменту діяти від вашого імені, але механізм інший:

	API-ключ	OAuth (кнопка "Увійти через Google/Slack")
Що доводить	Що звертається саме авторизована програма	Що саме ви особисто дозволили цей конкретний доступ
Термін дії	Зазвичай безстроковий, доки не відкличете вручну	Автоматично закінчується, зазвичай через хвилини-години, оновлюється непомітно
Обсяг доступу	Часто все-або-нічого на весь акаунт	Гнучкий — можна обмежити, наприклад, лише "читання повідомлень" без "надсилання від вашого імені"
Як підключається	Копіювання рядка в поле	Натискання "Підключити", вхід, підтвердження дозволів у спливному вікні

На практиці: якщо конектор у no-code інструменті показує "Підключити акаунт" зі спливним вікном входу — це OAuth. Якщо там просте текстове поле з написом "API Key" чи "Secret Key" — це ключ. Багато сервісів, орієнтованих на розробників (Stripe, OpenAI), взагалі не мають OAuth-варіанту, бо створені для серверної взаємодії, а не для сценарію "людина натискає кнопку підтвердження".

Чому безстроковий ключ — це реальний ризик

Ключ без автоматичного терміну дії означає: будь-хто, хто отримав його копію (через скріншот у чаті, закомічений конфіг-файл, розшарену таблицю), має доступ до нього доти, доки ви самі не помітите й не відкличете вручну. На відміну від OAuth-токена, тут немає автоматичного "запобіжника" в дизайні системи — вся безпека тримається виключно на тому, що ключ лишається секретним.

Типові помилки саме в no-code-контексті

Ключ вставлений у публічну чи розшарену Google Таблицю. Поширений патерн — зберігати конфіг-значення (включно з ключами) прямо в таблиці, з якої воркфлоу їх читає. Якщо доступ до таблиці налаштований "будь-хто за посиланням" — ключ фактично публічний.

Ключ залишається в експортованому воркфлоу, яким ділились на форумі для допомоги. Експорт Zap-а, сценарію Make чи JSON-файлу воркфлоу n8n для прохання про допомогу на форумі може випадково нести ключ усередині збережених креденшлів ноди чи захардкодженого значення — завжди перевіряйте вміст перед публічним шарингом.

Ключ ніколи не оновлюється після звільнення співробітника чи підрядника. На відміну від OAuth-підключення, прив'язаного до логіну конкретної людини (яке ламається одразу, як тільки в неї забирають доступ), спільний API-ключ продовжує працювати для будь-кого, у кого лишилась його копія, — доки хтось свідомо не згенерує новий.

Ключ вставлений прямо в URL замість заголовка запиту. Деякі старіші чи прості API приймають ключ як параметр URL (?api_key=abc123). URL-адреси за замовчуванням логуються проксі, історією браузера, аналітичними інструментами — якщо сервіс підтримує передачу ключа через заголовок запиту, саме так і варто робити, а не через URL.

Що робити, якщо ключ витік

Негайно відкликати ("regenerate") його в панелі сервісу-джерела — це миттєво деактивує старий ключ і видає новий. Потім оновити всі місця, де використовувався старий ключ (кожен Zap, сценарій Make, credential n8n), перш ніж щось спробує запуститись зі старим, уже мертвим ключем і впаде з помилкою. "Скасувати витік" неможливо — відкликання це єдине реальне рішення, а не ротація "коли буде зручно".

Якщо після заміни ключа воркфлоу все одно видає помилку авторизації — далі це вже питання діагностики конкретного інструменту: чому Zap у Zapier не спрацьовує розбирає коди 401/403 детальніше.

Часті питання

Чи це те саме, що звичайний пароль?

Функціонально схоже — обидва підтверджують особу для доступу — але пароль ідентифікує людину, що заходить в інтерфейс, а API-ключ ідентифікує програму, що робить автоматичні запити. Більшість сервісів дозволяють створити кілька API-ключів на один акаунт (по одному на кожну інтеграцію), тож можна відкликати один, не ламаючи решту підключень — зі звичайним паролем акаунта так не вийде.

Чому в n8n/Zapier/Make для одного сервісу просять API-ключ, а для іншого відкривають вікно входу?

Залежить виключно від того, що підтримує сам сервіс, а не від no-code інструменту. Сервіси, орієнтовані на розробників (Stripe, OpenAI), зазвичай мають лише API-ключі. Споживчі платформи з власною системою входу (Google, Slack) зазвичай підтримують OAuth, і no-code інструменти віддають перевагу саме йому, коли є вибір.

Чи можна обмежити, що саме дозволено робити конкретним ключем?

Залежить від сервісу — деякі дозволяють обмежити ключ лише читанням чи конкретним проєктом/ресурсом при генерації, інші видають один ключ з повним доступом до акаунта без можливості звузити. Перевіряйте екран генерації ключа в самому сервісі, перш ніж припускати, що ключ такий вузький, як хотілося б.

Чи безпечно зберігати API-ключ прямо в підключенні n8n/Zapier/Make?

Так — саме для цього ці поля підключення й створені, і надійні платформи зберігають ключ у зашифрованому вигляді, а не відкритим текстом. Ризик не в збереженні в конекторі, а в подальшому копіюванні кудись іще (таблиця, спільний документ, публічний репозиторій), де він уже не захищений так само.

Дата останньої перевірки актуальності: 28 серпня 2026 р.