Вы решили подключить нейросеть к собственному сайту. Зарегистрировались в OpenRouter, нашли подходящую модель и дошли до запроса, в котором требуется API key. Ключ нужен, чтобы сервис понимал, от чьего имени поступает запрос. Но обращаться с ним нужно как с секретом. Если вставить ключ в браузерный код или опубликовать его вместе с проектом, посторонние смогут использовать ваш доступ.
Разберём создание, проверку и хранение ключа на примере приложения с Python и Django.
Где получить ключ OpenRouter
Откройте раздел API Keys в OpenRouter и создайте новый ключ. При создании укажите понятное название, например my-ai-project, чтобы позднее отличать его от других.
Для отдельного проекта лучше использовать отдельный ключ. Так проще отслеживать использование и отключать доступ, если он больше не нужен. В настройках ключа можно задать лимит расходов. Это ограничивает последствия утечки или ошибки в приложении. Следите также за сроком действия ключа и удаляйте ключи, которыми уже не пользуетесь.
Сохраните выданное значение в безопасном месте. В дальнейшем приложение будет передавать его в HTTP-заголовке Authorization.
Почему ключ нельзя оставлять в браузере
Представим, что Next.js отправляет запрос непосредственно в OpenRouter, а ключ хранится в JavaScript страницы. Посетитель может открыть инструменты разработчика и посмотреть сетевые запросы или загруженные файлы. Даже если значение находится в переменной с неприметным названием, оно остаётся доступным клиенту. Поэтому внешние запросы с секретным ключом выполняют на сервере. В приложении с Django и Next.js браузер обращается к собственному backend, а Django уже использует ключ для подключения к OpenRouter.
В Next.js переменные с префиксом NEXT_PUBLIC_ предназначены для клиентского кода. Секретный ключ OpenRouter нельзя хранить под таким именем.
Сохраняем ключ отдельно от исходного кода
Для Python-приложения используем переменную окружения OPENROUTER_API_KEY. В локальном терминале Linux или macOS её можно задать так.
export OPENROUTER_API_KEY="ваш_ключ"
В production значение задают в настройках окружения хостинга. Его не нужно записывать в Git-репозиторий.
В Python ключ читается через os.environ.
import os
api_key = os.environ["OPENROUTER_API_KEY"]
Так в программе остаётся только название переменной, а само секретное значение поступает из окружения.
При работе с .env файлами проверьте, что файл с реальными секретами исключён из Git. Для примера настроек можно использовать .env.example, в котором перечислены названия переменных без настоящих ключей.
Проверяем, что ключ работает
Не обязательно сразу отправлять запрос языковой модели. OpenRouter предоставляет отдельный endpoint для информации о текущем API-ключе.
Установим библиотеку requests.
pip install requests
Затем выполним небольшой запрос.
import os
import requests
response = requests.get(
"https://openrouter.ai/api/v1/key",
headers={
"Authorization": (
f"Bearer {os.environ['OPENROUTER_API_KEY']}"
),
},
timeout=15,
)
response.raise_for_status()
data = response.json()["data"]
print("Ключ активен")
print("Использование:", data.get("usage"))
print("Лимит:", data.get("limit"))
Этот запрос проверяет авторизацию и возвращает сведения об использовании ключа. Он не генерирует текст и не выбирает модель. При этом значения лимитов и доступные поля зависят от настроек ключа. Если получен ответ 401, проверьте значение переменной окружения и корректность передаваемого ключа. 403 требует проверки условий доступа, а 429 может означать ограничение по частоте запросов.
Для диагностики достаточно кода ответа и сообщения API. Не выводите секретное значение в логи, скриншоты и сообщения об ошибках.
Что делать при утечке ключа
Ключ может случайно попасть в публичный репозиторий, текст сообщения или журнал приложения. Простое удаление строки из последнего коммита не делает его снова секретным. Значение могло остаться в истории Git или быть скопировано. В такой ситуации отключите скомпрометированный ключ в OpenRouter, создайте новый и обновите значение переменной окружения на сервере. После этого проверьте использование старого ключа и настройки лимитов.
Отдельные ключи для разработки и production упрощают такую замену. При этом пользовательский интерфейс продолжает обращаться к вашему backend, поэтому менять код браузера не требуется.
Что происходит после проверки ключа
Когда ключ успешно проходит проверку, можно переходить к запросу модели. Для первого подключения бесплатной LLM на Python есть отдельная статья «Как подключить бесплатную нейросеть к своему приложению».
Следующий этап разработки связан уже с поведением AI-сервиса. Придётся учитывать ограничения моделей, ошибки провайдеров и переключение между доступными вариантами. Эти сценарии подробнее разобраны в моей статье на Habr об агрегаторе LLM.
В AI-Chat можно посмотреть, как выглядит приложение, в котором пользовательский интерфейс работает вместе с серверным API.
Курс «AI на Django и Next II» проходит путь от подключения моделей до серверной логики, авторизации и приложения на Django и Next.js.
Работа с API начинается с простого правила. Браузер обращается к вашему серверу, сервер хранит ключ и выполняет запрос от имени приложения.