URL Base da API OpenAI (2026): Endpoints Diretos e Compatíveis

URL Base da API OpenAI (2026): Endpoints Diretos e Compatíveis

Resposta rápida: a URL base oficial da API OpenAI é https://api.openai.com/v1. Use-a como base_url ou baseURL do SDK e deixe que o SDK acrescente o caminho do recurso. Endpoints completos comuns são https://api.openai.com/v1/responses e https://api.openai.com/v1/chat/completions.

Para o gateway compatível com OpenAI da Flatkey, use https://router.flatkey.ai/v1 como URL base. O endpoint correspondente de conclusões de chat é https://router.flatkey.ai/v1/chat/completions. Não cole o caminho completo /chat/completions em um campo do SDK que espera apenas uma URL base.

Tabela de URL base da API OpenAI

URL base vs. endpoint: a diferença

Uma URL base é o prefixo compartilhado configurado uma única vez em um SDK. Um endpoint é o caminho completo para uma operação da API. Misturá-los causa as falhas de integração mais comuns:

• 404 Not Found: você forneceu o caminho errado ou duplicou /v1.
• 401 Unauthorized: a chave não pertence à URL base que você está chamando.
• /v1/v1/...: tanto a URL base configurada quanto o código do cliente acrescentaram /v1.
• .../chat/completions/chat/completions: um endpoint completo foi passado onde o SDK esperava apenas a URL base.

Use uma única fonte de verdade para a URL base, mantenha as chaves em variáveis de ambiente e execute uma pequena solicitação de /models ou de chat antes de migrar o tráfego de produção.

O que muda com um gateway de API compatível com OpenAI

A principal mudança é operacional, não conceitual.

É por isso que as equipes procuram um openai compatible api gateway em primeiro lugar. Elas não estão pedindo um novo formato de prompt. Estão pedindo menos risco de reescrita.

Use esta lista de verificação de migração antes de alterar a produção

A maneira mais segura de adotar um openai compatible api gateway é tratá-lo como uma mudança controlada de integração, não como um projeto amplo de abstração.

1. Liste os endpoints exatos da OpenAI que você usa hoje. A maioria das equipes pensa que usa “a API OpenAI” quando, na verdade, usa um subconjunto menor, como conclusões de chat, responses, embeddings ou geração de imagens.
2. Confirme quais chamadas devem permanecer inalteradas no código da aplicação. Isso mantém o escopo realista e protege a alegação de “migração mínima”.
3. Verifique se o SDK atual já oferece suporte a uma URL base personalizada. Os clientes oficiais atuais da OpenAI para Python e Node oferecem.
4. Escolha primeiro um fluxo de trabalho de staging. Comece pela rota que já se ajusta a um formato padrão de solicitação da OpenAI.
5. Verifique os modelos de destino ao vivo antes da implementação. Não confie em capturas de tela antigas ou em suposições baseadas em catálogos desatualizados.
6. Documente a regra de fallback. Os revisores devem saber se a rota pode trocar de modelo, falhar de forma fechada ou entrar em fila.
7. Aprove a ressalva de compatibilidade. A redação publicada deve dizer “compatível com OpenAI” para a superfície de solicitação compatível, e não “totalmente idêntico à OpenAI”.

Esta lista de verificação é o que torna um openai compatible api gateway confiável para revisão de produção.

Exemplos de código com alterações mínimas

Os SDKs oficiais atuais da OpenAI já documentam o suporte a URL base personalizada. Esse é o motivo mecânico pelo qual um openai compatible api gateway pode ser uma migração de baixo atrito quando o gateway preserva o formato de solicitação no estilo OpenAI que você já usa.

Exemplo em 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)

Exemplo em 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);

Exemplo em 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." }
    ]
  }'

Para muitas equipes, esta é a primeira prova de que um gateway de API compatível com OpenAI não precisa significar uma reescrita do cliente. A restrição importante é que o fluxo de trabalho escolhido deve se adequar à superfície de solicitações compatível.

O que verificar antes de dizer que a migração é “direta”

É aqui que a maioria das páginas sobre gateway de API compatível com OpenAI se torna imprecisa. “Direta” é amplo demais, a menos que você defina o limite.

Use esta tabela na revisão:

Um gateway de API compatível com OpenAI é valioso quando essas verificações são aprovadas com menos atrito do que migrações separadas de provedores.

Uma sequência prática de implantação

Este é o caminho de implantação mais simples para um gateway de API compatível com OpenAI quando você deseja alterações mínimas no código:

1. Faça o inventário do caminho de chamada atual. Registre a versão atual do SDK, a família de endpoints, os IDs de modelo, as configurações de streaming e as premissas de repetição.
2. Altere uma URL base no ambiente de homologação. Primeiro, mantenha o mesmo padrão de cliente. Não agrupe isso com alterações não relacionadas de prompt ou modelo.
3. Mantenha um modelo aprovado para o primeiro teste. O primeiro critério de sucesso é a compatibilidade de transporte, não uma ampla cobertura de modelos.
4. Execute verificações de formato de resposta e erro. Compare saídas, códigos de status, expectativas de latência e comportamento de logs.
5. Revise a política de roteamento de modelos. Decida se a rota é fixa em um modelo, se pode fazer failover para uma classe equivalente ou se deve falhar de forma fechada.
6. Expanda somente após a confirmação do catálogo ativo. Em 15 de julho de 2026, o feed público de preços da Flatkey mostrava 170 linhas no total e 95 linhas disponíveis, mas a implantação em produção ainda exige validação exata do modelo no dia do lançamento.

Essa sequência é o que transforma um gateway de API compatível com OpenAI em uma camada de controle de migração, em vez de mais uma incógnita de integração.

Em que isso difere de uma migração direta de provedor

A documentação dos provedores já mostra que a compatibilidade no estilo OpenAI está se tornando normal. O Google documenta o acesso ao Gemini por meio de bibliotecas OpenAI. A DeepSeek documenta compatibilidade com OpenAI e Anthropic. Mas cada provedor ainda tem sua própria chave, URL base e limite operacional.

Essa é a lacuna abordada por um gateway de API compatível com OpenAI. Em vez de ensinar a cada equipe uma nova configuração específica de provedor, você pode centralizar a superfície de migração e direcionar o trabalho de revisão para aprovação de modelos, observabilidade e política de roteamento de modelos.

Isso também explica por que a mensagem atual da Flatkey é mais forte do que “funciona com o SDK da OpenAI”. O benefício mais importante é que um gateway de API compatível com OpenAI pode consolidar o acesso e a revisão sem forçar uma reescrita imediata da aplicação.

Redação de conformidade que os revisores podem aprovar

Use uma redação como esta na revisão final de publicação:

Evite formulações como estas, a menos que os revisores possam comprová-las:

Essas ressalvas tornam a proposta de gateway de API compatível com OpenAI mais crível, não mais fraca.

Quando um gateway de API compatível com OpenAI é a escolha certa

Um gateway de API compatível com OpenAI geralmente é a escolha certa quando:

• sua equipe já depende de fluxos de cliente no estilo OpenAI e quer o caminho de migração menos disruptivo
• mais de uma família de modelos já está no escopo
• você precisa de um único lugar para revisar acesso, uso e rotas aprovadas
• as mudanças de modelo ocorrem com frequência suficiente para justificar uma política compartilhada de roteamento de modelos
• você quer uma migração controlada antes de considerar recursos mais avançados de gateway

Se essas condições não forem verdadeiras, uma configuração direta com o provedor ainda poderá ser mais simples. Este artigo deve ser honesto sobre essa contrapartida.

Equipes AWS: a URL base compatível com OpenAI do Bedrock

Se seus modelos são executados na AWS, o Amazon Bedrock disponibiliza sua própria URL base compatível com OpenAI, https://bedrock-runtime.{region}.amazonaws.com/openai/v1, autenticada com chaves de API do Bedrock. Nosso guia da API compatível com OpenAI do Amazon Bedrock aborda endpoints, chaves, IDs de modelo e a limitação de /models.

Conclusão

O valor de um gateway de API compatível com OpenAI não está em inventar um novo padrão de API. O valor está em permitir que as equipes preservem uma integração familiar no estilo OpenAI enquanto transferem o acesso, a aprovação de modelos e o controle de implantação para trás de uma única camada revisável.

Para a Flatkey, a alegação mais sólida e revisável é simples: mantenha o padrão de cliente que você já usa, altere a URL base para https://router.flatkey.ai/v1, valide o fluxo de trabalho exato compatível e aprove a política de roteamento de modelos antes de ampliar o tráfego. Essa é a lista de verificação de migração de que os desenvolvedores realmente precisam.