Базовый URL OpenAI API (2026): прямые и совместимые эндпоинты

Базовый URL OpenAI API (2026): прямые и совместимые эндпоинты

Краткий ответ: официальный базовый URL OpenAI API — https://api.openai.com/v1. Используйте его как base_url или baseURL в SDK, после чего SDK добавит путь к ресурсу. Распространённые полные эндпоинты: https://api.openai.com/v1/responses и https://api.openai.com/v1/chat/completions.

Для совместимого с OpenAI шлюза Flatkey используйте https://router.flatkey.ai/v1 в качестве базового URL. Соответствующий эндпоинт chat completions: https://router.flatkey.ai/v1/chat/completions. Не вставляйте полный путь /chat/completions в поле SDK, которое ожидает только базовый URL.

Таблица базовых URL OpenAI API

Базовый URL и эндпоинт: в чём разница

Базовый URL — это общий префикс, который один раз настраивается в SDK. Эндпоинт — это полный путь для одной операции API. Их смешение вызывает наиболее распространённые ошибки интеграции:

• 404 Not Found: указан неверный путь или /v1 продублирован.
• 401 Unauthorized: ключ не принадлежит базовому URL, к которому выполняется запрос.
• /v1/v1/...: и настроенный базовый URL, и клиентский код добавили /v1.
• .../chat/completions/chat/completions: полный эндпоинт был передан туда, где SDK ожидал только базовый URL.

Используйте единый источник истины для базового URL, храните ключи в переменных окружения и выполните небольшой запрос к /models или chat-запрос перед переносом рабочего трафика.

Что меняет API-шлюз, совместимый с OpenAI

Главное изменение носит операционный, а не концептуальный характер.

Именно поэтому команды в первую очередь ищут openai compatible api gateway. Им не нужен новый формат промптов. Они хотят снизить риск переработки.

Используйте этот чек-лист миграции перед изменением production-среды

Самый безопасный способ внедрить openai compatible api gateway — рассматривать его как контролируемое изменение интеграции, а не как проект по созданию всеобъемлющей абстракции.

1. Составьте список точных эндпоинтов OpenAI, которые вы используете сейчас. Большинство команд считают, что используют «OpenAI API», хотя на деле применяют меньший набор, например chat completions, responses, embeddings или генерацию изображений.
2. Подтвердите, какие вызовы должны остаться неизменными в коде приложения. Это позволяет честно определить объём работ и защищает заявление о «минимальной миграции».
3. Проверьте, поддерживает ли текущий SDK пользовательский базовый URL. Текущие официальные клиенты OpenAI для Python и Node его поддерживают.
4. Сначала выберите один сценарий для staging-среды. Начните с маршрута, который уже соответствует стандартной форме запроса OpenAI.
5. Перед развёртыванием проверьте доступность целевых моделей. Не полагайтесь на старые скриншоты или устаревшие предположения о каталоге.
6. Зафиксируйте правило резервного поведения. Проверяющие должны знать, может ли маршрут переключать модели, завершаться с ошибкой или ставить запрос в очередь.
7. Утвердите оговорку о совместимости. В опубликованной формулировке следует говорить «совместимый с OpenAI» для поддерживаемой поверхности запросов, а не «полностью идентичный OpenAI».

Именно этот чек-лист делает openai compatible api gateway убедительным для проверки перед production-развёртыванием.

Примеры кода с минимальными изменениями

Текущие официальные SDK OpenAI уже документируют поддержку пользовательского базового URL. Это техническая причина, по которой openai compatible api gateway может обеспечить миграцию с минимальными трудностями, если шлюз сохраняет уже используемую вами форму запроса в стиле OpenAI.

Пример на Python

from openai import OpenAI

client = OpenAI(
    api_key="sk-fk-your-flatkey-key",
    base_url="https://router.flatkey.ai/v1",
)

response = client.chat.completions.create(
    model="gpt-5.4-mini",
    messages=[
        {"role": "system", "content": "You are a concise assistant."},
        {"role": "user", "content": "Return a one-line health check."},
    ],
)

print(response.choices[0].message.content)

Пример для Node

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.FLATKEY_API_KEY,
  baseURL: "https://router.flatkey.ai/v1",
});

const response = await client.chat.completions.create({
  model: "gpt-5.4-mini",
  messages: [
    { role: "system", content: "You are a concise assistant." },
    { role: "user", content: "Return a one-line health check." },
  ],
});

console.log(response.choices[0].message.content);

Пример cURL

curl -X POST "https://router.flatkey.ai/v1/chat/completions" \
  -H "Authorization: Bearer $FLATKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4-mini",
    "messages": [
      { "role": "user", "content": "Return a one-line health check." }
    ]
  }'

Для многих команд это первое доказательство того, что совместимый с OpenAI API шлюз не обязательно требует переписывания клиента. Важное ограничение состоит в том, что выбранный вами рабочий процесс должен укладываться в поддерживаемый набор запросов.

Что проверить, прежде чем назвать миграцию «бесшовной»

Именно здесь большинство страниц о совместимых с OpenAI API шлюзах становятся неточными. «Бесшовная» — слишком широкая характеристика, если не определить границы.

Используйте эту таблицу при проверке:

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

Практическая последовательность развертывания

Это наиболее простой путь развертывания совместимого с OpenAI API шлюза, когда требуется минимум изменений в коде:

1. Инвентаризируйте текущий путь вызова. Зафиксируйте текущую версию SDK, семейство эндпоинтов, идентификаторы моделей, настройки потоковой передачи и предположения о повторных попытках.
2. Измените один базовый URL в стейджинге. Сначала сохраните тот же паттерн клиента. Не объединяйте это с несвязанными изменениями промптов или моделей.
3. Оставьте одну одобренную модель для первого теста. Первый критерий успеха — совместимость транспорта, а не широкий охват моделей.
4. Проверьте форму ответов и ошибок. Сравните результаты, коды состояния, ожидаемые задержки и поведение логирования.
5. Проверьте политику маршрутизации моделей. Решите, закреплен ли маршрут за одной моделью, может ли переключаться на эквивалентный класс или должен завершаться ошибкой без переключения.
6. Расширяйте использование только после подтверждения актуального каталога. На 15 июля 2026 года публичная лента цен Flatkey показывала 170 строк всего и 95 доступных строк, однако для развертывания в производственной среде все равно требуется точная проверка моделей в день выпуска.

Именно эта последовательность превращает совместимый с OpenAI API шлюз в уровень контроля миграции, а не в еще одну неизвестную интеграцию.

Чем это отличается от прямой миграции к провайдеру

Документация провайдеров уже показывает, что совместимость в стиле OpenAI становится нормой. Google документирует доступ к Gemini через библиотеки OpenAI. DeepSeek документирует совместимость с OpenAI и Anthropic. Но у каждого провайдера по-прежнему есть собственные ключ, базовый URL и операционные границы.

Именно этот пробел устраняет совместимый с OpenAI API шлюз. Вместо того чтобы обучать каждую команду новой настройке для конкретного провайдера, вы можете централизовать поверхность миграции и перенести фокус проверки на одобрение моделей, наблюдаемость и политику маршрутизации моделей.

Это также объясняет, почему текущий тезис Flatkey сильнее, чем «он работает с OpenAI SDK». Более важное преимущество заключается в том, что совместимый с OpenAI API шлюз может консолидировать доступ и проверку, не вынуждая немедленно переписывать приложение.

Формулировки для соответствия требованиям, которые могут одобрить проверяющие

Используйте такие формулировки при финальной проверке перед публикацией:

Избегайте таких формулировок, если проверяющие не могут их подтвердить:

Эти оговорки делают описание шлюза API, совместимого с OpenAI более убедительным, а не более слабым.

Когда шлюз API, совместимый с OpenAI, является правильным решением

Шлюз API, совместимый с OpenAI, обычно является правильным решением, когда:

• ваша команда уже использует клиентские потоки в стиле OpenAI и хочет выбрать путь миграции с наименьшими изменениями
• в области применения уже находится более одного семейства моделей
• вам нужно единое место для проверки доступа, использования и утверждённых маршрутов
• изменения моделей происходят достаточно часто, чтобы оправдать общую политику маршрутизации моделей
• вы хотите выполнить контролируемую миграцию, прежде чем рассматривать более продвинутые возможности шлюза

Если эти условия не выполняются, прямая настройка у провайдера всё ещё может быть проще. В статье следует честно говорить об этом компромиссе.

Команды AWS: базовый URL Bedrock, совместимый с OpenAI

Если ваши модели работают в AWS, Amazon Bedrock предоставляет собственный базовый URL, совместимый с OpenAI: https://bedrock-runtime.{region}.amazonaws.com/openai/v1. Аутентификация выполняется с помощью ключей API Bedrock. В нашем руководстве по API Amazon Bedrock, совместимому с OpenAI рассматриваются эндпоинты, ключи, идентификаторы моделей и ограничение /models.

Заключение

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

Для Flatkey наиболее убедительное и проверяемое утверждение простое: сохраните используемый вами клиентский шаблон, измените базовый URL на https://router.flatkey.ai/v1, проверьте точный поддерживаемый сценарий и утвердите политику маршрутизации моделей, прежде чем расширять трафик. Это контрольный список миграции, который действительно нужен разработчикам.