Исправьте ошибку «API Key Not Found in Cookies»

TL;DR

• API key not found in cookies почти никогда не означает, что ваш ключ неверный. Это значит, что браузерное приложение, сохранившее ваш ключ в cookie, не может прочитать этот cookie обратно.
• Обычный виновник: сторонние cookie заблокированы. Safari, Brave, Firefox и каждое окно Incognito блокируют их по умолчанию — поэтому cookie с вашим ключом незаметно не сохраняется.
• Быстрое исправление: разрешите cookie для точного домена приложения, выйдите из аккаунта и войдите снова, затем заново вставьте свой ключ. Другой браузер или Incognito? Вот почему он «исчез».
• Постоянное исправление (для разработчиков): перестаньте полагаться на хранилище cookie. Отправляйте свой ключ в заголовке Authorization: Bearer на стабильный endpoint. Нет cookie — нет проблемы с cookie.

Если вы попали сюда потому, что какой-то гайд сказал вам, что это ошибка "Cursor" или "Windsurf", — это не так. Это сообщение приходит из браузерных приложений, которые хранят ваш API-ключ на стороне клиента, и исправление никак не связано с вашей IDE.

Что на самом деле означает "API key not found in cookies"?

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

Вот механизм. Некоторые веб-приложения — AI chat frontends, reverse-proxy dashboards, несколько SaaS consoles — не хотят хранить ваш ключ на своём сервере. Поэтому, когда вы вставляете его, они сохраняют его в [cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies) (или в сессии на основе cookie) в вашем собственном браузере. Затем каждый запрос считывает ключ обратно из этого cookie. Когда cookie отсутствует, заблокирован, истёк или привязан к домену, на котором вы сейчас не находитесь, чтение возвращает пустой результат. Вы получаете API key not found in cookies.

Так что это ошибка состояния авторизации на стороне клиента, а не ошибка "invalid credentials". Никто не отклонил ваш ключ. Приложение просто не смогло найти его, чтобы отправить.

Какие приложения выдают эту ошибку — и почему дело не в вашем API-ключе

Любое браузерное приложение, которое хранит ваш API-ключ в cookie, может выдать её. Это честный ответ, и его стоит явно проговорить, потому что самый высокоранжируемый гайд по этому запросу обвиняет IDE-инструменты вроде Cursor, Windsurf и Cline — с конкретными номерами версий, которые не соответствуют реальной ошибке на основе cookie. Эти инструменты хранят ключи в локальных config files, а не в browser cookies.

Где вы действительно видите API key not found in cookies:

Общий момент: ваш ключ никогда не доходил до server-side account. Он находится в вашем браузере, и ваш браузер потерял его из виду. Это меняет рамку всех исправлений ниже — вы чините не ключ, а cookie storage.

Почему API key cookie постоянно исчезает?

Потому что современные браузеры по умолчанию блокируют сторонние cookie, а cookie с вашим ключом часто считается именно таким. Это первопричина, которую большинство гайдов в стиле "clear your cache" пропускают.

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

Так что тот же ключ, который "works on my laptop", ломается в private window, в жёстко настроенном рабочем браузере или после обновления браузера, которое переключило privacy default. Handshake выглядит завершённым — приложение просто не может записать или прочитать cookie после этого.

Ещё несколько причин, по которым cookie пропадает:

• Вы очистили cookies (или использовали "clear browsing data") — key cookie удалился вместе со всем остальным.
• Другой browser или device — cookies не синхронизируются между ними, поэтому ключа там нет.
• Неверный domain или subdomain — cookie, установленный на app.example.com, не виден на example.com, и наоборот.
• Сдвиг системных часов — cookies несут timestamp истечения срока. Если ваши часы отстают или спешат на минуты, браузер может считать свежий cookie уже истёкшим.
• SSL-inspecting corporate proxy или VPN — некоторые переписывают или отбрасывают заголовки Set-Cookie, поэтому cookie вообще не попадает в браузер.

Как исправить "API key not found in cookies" прямо сейчас?

Идите по этому списку — первые два пункта решают большинство случаев меньше чем за минуту:

1. Разрешите cookies для точного домена приложения. В Chrome/Edge: Settings → Privacy and security → Third-party cookies → добавьте URL приложения в "Allowed to use third-party cookies." В Safari: Settings → Privacy → снимите флажок "Prevent cross-site tracking" (или добавьте site exception). В Firefox: shield icon в address bar → отключите Enhanced Tracking Protection для этого сайта.
2. Выйдите из аккаунта, войдите снова, затем заново вставьте свой ключ. Это заставляет приложение создать свежую session и записать чистый cookie. Это auth-state эквивалент выключить и включить снова.
3. Выйдите из Incognito/Private mode. Они блокируют сторонние cookies по замыслу, и ничего не сохраняется после закрытия окна. Используйте normal window и заново введите ключ.
4. Отключите ad blockers / privacy extensions для этого сайта. uBlock Origin, AdGuard и privacy add-ons могут блокировать subdomain, через который проходит cookie. Добавьте приложение в whitelist, перезагрузите, заново введите ключ.
5. Проверьте системные часы. Включите automatic date/time, чтобы NTP держал вас в синхронизации. Сдвинутые часы незаметно просрочивают хорошие cookies.
6. Убедитесь, что вы на точном URL, где был сохранён ключ. Если вы сохранили ключ на app.tool.com, cookie не появится на tool.com. Совпадение subdomain обязательно.
7. Сгенерируйте ключ заново в provider dashboard. Если teammate rotated or deleted it, cookie теперь указывает на мёртвый ключ. Создайте новый, вставьте его — готово.

Если вы в corporate network и ничего из этого не сохраняется, проверьте через phone hotspot в течение двух минут. Если там работает, SSL-inspecting proxy съедает ваши cookies — попросите IT исключить домен приложения из проверки.

Как избавиться от этой ошибки навсегда?

Перестаньте зависеть от browser cookie для передачи ключа. Если вы контролируете код, отправляйте ключ в request header вместо этого — cookies опциональны, headers — нет.

Ключи, хранящиеся в cookie, хрупки по своей природе: они живут в одном browser profile, наследуют privacy rules этого браузера и исчезают при очистке cache. Header-based auth обходит всё это. Ключ передаётся в запросе:

curl https://api.velokey.ai/v1/chat/completions \
  -H "Authorization: Bearer $YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Нет cookie jar, нет third-party cookie policy, нет сюрприза Incognito. Тот же call выполняется из script, server, CI job или backend, с которым общается ваш frontend, — и ни у чего из этого изначально нет проблемы с cookie. Если вы строите browser app, надёжный паттерн — хранить ключ на собственном backend и заставить браузер обращаться к *вашему* server, а не вставлять сырой provider key в client-side cookie.

Именно поэтому API gateways не сталкиваются с этой ошибкой. Gateway вроде [Velokey](https://api.velokey.ai) даёт вам один ключ, который открывает доступ ко многим моделям — [GPT-5.6](/model/gpt-5.6), [Claude Opus 4.8](/model/claude-opus-4-8), [Claude Sonnet 5](/model/claude-sonnet-5) — через единый OpenAI-compatible endpoint, и этот ключ каждый раз передаётся в заголовке Authorization. Там нет cookie, который можно потерять. Если вы вставляли provider key в chat frontend просто чтобы попробовать модель, прямой вызов стабильного endpoint одновременно проще и устойчивее к поломкам. По вопросам pricing смотрите наш гайд по Claude API pricing; полный walkthrough — как вызвать API с ключом — покрывает настройку от начала до конца.

Краткая справка по исправлениям

Часто задаваемые вопросы

"API key not found in cookies" относится к одному конкретному приложению?

Нет. Это универсальное сообщение от любого browser app, которое хранит ваш API-ключ в cookie, — AI chat frontends, reverse-proxy dashboards и некоторые web playgrounds используют такой pattern. Гайды, которые привязывают его к одной IDE, гадают. Исправление одинаковое в любом случае: восстановить или заменить cookie, в котором лежит ваш ключ.

Удалит ли очистка cookies мой API-ключ навсегда?

Нет. Ваш ключ находится в provider dashboard, а не в cookie. Очистка cookies удаляет только локальную копию, которую читало приложение. Вас разлогинит и попросят снова вставить ключ, но сам ключ останется целым. Скопируйте его у provider перед очисткой, чтобы вы могли заново его ввести.

Может ли Incognito или private mode вызвать эту ошибку?

Да, стабильно. Окна Incognito, Private и InPrivate по умолчанию блокируют сторонние cookies и стирают всё при закрытии. Если вы сохранили ключ в private window, он уже исчез. Переключитесь в normal window, заново введите ключ, и он будет сохраняться между сессиями.

Может ли VPN или corporate proxy спровоцировать это?

Может. SSL-inspecting corporate proxy или некоторые VPN переписывают или удаляют заголовок Set-Cookie, поэтому key cookie вообще не попадает в ваш браузер. Быстрый тест: переключитесь на phone hotspot на минуту. Если ошибка исчезнет, причина в сети — попросите IT добавить домен приложения в inspection bypass list.

Влияет ли эта ошибка на server-side API calls?

Нет. Server-to-server calls отправляют ключ в заголовке Authorization, и browser cookie там не участвует, поэтому такая ошибка там возникнуть не может. Она появляется только в browser apps, которые решили хранить ваш ключ client-side. Перенос auth в request header — ровно поэтому backends и scripts никогда её не видят.

Почему у API gateways или aggregators нет этой проблемы?

Потому что они аутентифицируются через header, а не cookie. Вы отправляете Authorization: Bearer <key> в каждом запросе на стабильный endpoint, поэтому нет browser cookie, который можно заблокировать, просрочить или очистить. Это структурная причина, по которой gateway call продолжает работать в разных browsers, private windows и locked-down networks, где cookie-based frontend тихо ломается.