# OpenRouter API URL: какой адрес указывать в совместимом клиенте

Как настроить base URL OpenRouter и не получить неверный путь: адрес сервиса, метод Chat Completions, Responses API, прокси приложения и проверка конечного запроса.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/openrouter-base-url/
Language: ru

Для OpenAI-совместимого клиента OpenRouter обычно указывают базовый адрес `https://openrouter.ai/api/v1`. Но значение поля зависит от конкретного инструмента: один ожидает основу, другой — полный адрес метода. Поэтому правильная настройка начинается с документации самого клиента и проверки итогового HTTP-запроса.

Материал проверен 1 ноября 2026 года. Примеры показывают структуру адресов и не выполняют платных запросов автоматически.

## Различайте основу и полный путь

[OpenRouter Authentication](https://openrouter.ai/docs/api_reference/authentication) показывает использование единого адреса с совместимыми клиентами. При прямом HTTP-вызове к нему добавляют путь нужной операции. Полный адрес Chat Completions заканчивается на `/chat/completions`, а Responses — на `/responses`.

| Что запрашивает настройка | Что нужно передать |
| --- | --- |
| Base URL клиента, добавляющего методы | Основу `https://openrouter.ai/api/v1` |
| Полный URL прямого HTTP-запроса Chat Completions | Адрес с `/chat/completions` в конце |
| Полный URL прямого HTTP-запроса Responses | Адрес с `/responses` в конце |

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

## Найдите, кто добавляет суффикс

Откройте сетевой журнал тестового клиента или включите безопасное журналирование адреса на сервере. Важно увидеть путь без содержимого секретных заголовков. Частая ошибка интеграции — повтор `/api/v1/api/v1` либо двойное добавление `/chat/completions`.

Проверьте завершающий слеш и правила объединения строк. Например, библиотека может считать путь, начинающийся с `/`, абсолютным относительно домена и отбросить часть основы. Такой результат определяется библиотекой, поэтому догадки по внешнему виду поля недостаточно.

## Не смешивайте форматы тела

Даже корректный URL не исправляет неверный формат сообщения. [Обзор API OpenRouter](https://openrouter.ai/docs/api_reference/overview) описывает поддерживаемую схему запросов. Для выбранной операции используйте её параметры, а не механическое переименование поля из другого протокола.

Условный пример: команда меняет только адрес, а оставляет тело из старого интеграционного адаптера. Ошибка сервера в таком случае не доказывает отсутствие модели. Сначала сравните метод, заголовок Content-Type и минимальное тело с официальным примером для того же endpoint.

## Проверьте промежуточный сервер

Если приложение обращается через собственный backend, у него есть два адреса: внутренний маршрут приложения и внешний OpenRouter API URL. В браузере пользователь должен видеть первый. Второй и ключ доступа находятся в серверной конфигурации.

Запишите цепочку полностью: браузер, backend, внешний API. Если ошибка возникает на внутреннем маршруте, изменение модели не поможет. Если запрос дошёл до внешнего сервиса, сохраните его статус и идентификатор для следующего этапа диагностики.

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

## Зафиксируйте работающую настройку

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

Далее полезны материалы о [ключе приложения](/ru/journal/openrouter-api-key-setup/) и [разборе ошибки 404](/ru/journal/openrouter-404-error/). Для оператора собственного инференса совместимый адрес — только часть готовности сервиса.