OpenAI API Base URL (2026): Direkte und kompatible Endpunkte

OpenAI API Base URL (2026): Direkte und kompatible Endpunkte

Kurzantwort: Die offizielle OpenAI-API-Basis-URL lautet https://api.openai.com/v1. Verwenden Sie sie als base_url oder baseURL des SDKs und lassen Sie das SDK anschließend den Ressourcenpfad anhängen. Häufige vollständige Endpunkte sind https://api.openai.com/v1/responses und https://api.openai.com/v1/chat/completions.

Verwenden Sie für Flatkeys OpenAI-kompatibles Gateway https://router.flatkey.ai/v1 als Basis-URL. Der entsprechende Chat-Completions-Endpunkt lautet https://router.flatkey.ai/v1/chat/completions. Fügen Sie nicht den vollständigen Pfad /chat/completions in ein SDK-Feld ein, das nur eine Basis-URL erwartet.

Tabelle der OpenAI-API-Basis-URLs

Basis-URL vs. Endpunkt: der Unterschied

Eine Basis-URL ist das gemeinsame Präfix, das einmalig in einem SDK konfiguriert wird. Ein Endpunkt ist der vollständige Pfad für einen API-Vorgang. Eine Vermischung verursacht die häufigsten Integrationsfehler:

• 404 Not Found: Sie haben den falschen Pfad angegeben oder /v1 doppelt eingefügt.
• 401 Unauthorized: Der Schlüssel gehört nicht zu der Basis-URL, die Sie aufrufen.
• /v1/v1/...: Sowohl Ihre konfigurierte Basis-URL als auch der Clientcode haben /v1 angehängt.
• .../chat/completions/chat/completions: Ein vollständiger Endpunkt wurde übergeben, wo das SDK nur die Basis-URL erwartete.

Verwenden Sie eine zentrale Quelle für die Basis-URL, bewahren Sie Schlüssel in Umgebungsvariablen auf und führen Sie vor der Migration von Produktionsverkehr eine kleine /models- oder Chat-Anfrage aus.

Was ein OpenAI-kompatibles API-Gateway verändert

Die entscheidende Veränderung ist operativ, nicht konzeptionell.

Deshalb suchen Teams überhaupt nach einem openai compatible api gateway. Sie fragen nicht nach einem neuen Prompt-Format. Sie wollen weniger Risiko durch Umschreibungen.

Verwenden Sie diese Migrationscheckliste, bevor Sie die Produktion ändern

Die sicherste Art, ein openai compatible api gateway einzuführen, besteht darin, es als kontrollierte Integrationsänderung und nicht als umfassendes Abstraktionsprojekt zu behandeln.

1. Listen Sie die genauen OpenAI-Endpunkte auf, die Sie heute verwenden. Die meisten Teams glauben, sie verwendeten „die OpenAI API“, obwohl sie tatsächlich nur eine kleinere Teilmenge wie Chat Completions, Responses, Embeddings oder Bildgenerierung nutzen.
2. Bestätigen Sie, welche Aufrufe im Anwendungscode unverändert bleiben müssen. Dadurch bleibt der Umfang realistisch und die Behauptung einer „minimalen Migration“ wird abgesichert.
3. Prüfen Sie, ob Ihr aktuelles SDK bereits eine benutzerdefinierte Basis-URL unterstützt. Die aktuellen offiziellen OpenAI-Clients für Python und Node tun dies.
4. Wählen Sie zuerst einen Staging-Workflow aus. Beginnen Sie mit der Route, die bereits einem standardmäßigen OpenAI-Anfrageformat entspricht.
5. Überprüfen Sie vor dem Rollout, ob die Zielmodelle verfügbar sind. Verlassen Sie sich nicht auf alte Screenshots oder veraltete Katalogannahmen.
6. Halten Sie die Fallback-Regel schriftlich fest. Prüfer sollten wissen, ob die Route Modelle wechseln, geschlossen fehlschlagen oder Anfragen in eine Warteschlange stellen kann.
7. Genehmigen Sie den Kompatibilitätshinweis. Ihre veröffentlichte Formulierung sollte für die unterstützte Anfrageschnittstelle „OpenAI-kompatibel“ und nicht „vollständig identisch mit OpenAI“ lauten.

Diese Checkliste macht ein openai compatible api gateway für die Produktionsprüfung glaubwürdig.

Codebeispiele mit minimalen Änderungen

Die aktuellen offiziellen OpenAI-SDKs dokumentieren bereits die Unterstützung benutzerdefinierter Basis-URLs. Das ist der technische Grund, warum ein openai compatible api gateway eine reibungsarme Migration sein kann, wenn das Gateway die Anfragestruktur im OpenAI-Stil beibehält, die Sie bereits verwenden.

Python-Beispiel

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-Beispiel

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-Beispiel

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

Für viele Teams ist dies der erste Beweis dafür, dass ein OpenAI-kompatibles API-Gateway keine Überarbeitung des Clients bedeuten muss. Die wichtige Einschränkung ist, dass Ihr gewählter Workflow zur unterstützten Anfrageoberfläche passen muss.

Was Sie prüfen sollten, bevor Sie die Migration als „Drop-in“ bezeichnen

Hier werden die meisten Seiten zu OpenAI-kompatiblen API-Gateways nachlässig. „Drop-in“ ist zu weit gefasst, wenn Sie die Grenze nicht definieren.

Verwenden Sie diese Tabelle bei der Überprüfung:

Ein OpenAI-kompatibles API-Gateway ist wertvoll, wenn diese Prüfungen mit weniger Reibung bestehen als bei separaten Provider-Migrationen.

Eine praktische Rollout-Reihenfolge

Dies ist der sauberste Rollout-Pfad für ein OpenAI-kompatibles API-Gateway, wenn Sie minimale Codeänderungen wünschen:

1. Inventarisieren Sie den aktuellen Aufrufpfad. Dokumentieren Sie die aktuelle SDK-Version, Endpunktfamilie, Modell-IDs, Streaming-Einstellungen und Annahmen zu Wiederholungsversuchen.
2. Ändern Sie eine Base-URL in der Staging-Umgebung. Behalten Sie zunächst dasselbe Client-Muster bei. Bündeln Sie dies nicht mit unabhängigen Änderungen an Prompts oder Modellen.
3. Behalten Sie für den ersten Test ein freigegebenes Modell bei. Das erste Erfolgskriterium ist Transportkompatibilität, nicht eine breite Modellabdeckung.
4. Führen Sie Prüfungen der Antwort- und Fehlerstruktur durch. Vergleichen Sie Ausgaben, Statuscodes, Latenzerwartungen und Logging-Verhalten.
5. Überprüfen Sie die Modell-Routing-Richtlinie. Entscheiden Sie, ob die Route auf ein Modell festgelegt ist, auf eine gleichwertige Klasse ausweichen kann oder geschlossen fehlschlagen muss.
6. Erweitern Sie erst nach Bestätigung des Live-Katalogs. Am 15. Juli 2026 zeigte der öffentliche Pricing-Feed von Flatkey 170 Zeilen insgesamt und 95 verfügbare Zeilen, doch für den Produktions-Rollout ist weiterhin eine genaue Modellvalidierung am Tag der Bereitstellung erforderlich.

Diese Reihenfolge macht ein OpenAI-kompatibles API-Gateway zu einer Kontrollschicht für Migrationen statt zu einer weiteren unbekannten Integration.

Worin sich dies von einer direkten Provider-Migration unterscheidet

Provider-Dokumentationen zeigen bereits, dass Kompatibilität im OpenAI-Stil zur Normalität wird. Google dokumentiert Gemini-Zugriff über OpenAI-Bibliotheken. DeepSeek dokumentiert Kompatibilität mit OpenAI und Anthropic. Dennoch hat jeder Provider weiterhin seinen eigenen Schlüssel, seine eigene Base-URL und seine eigene betriebliche Grenze.

Diese Lücke schließt ein OpenAI-kompatibles API-Gateway. Anstatt jedem Team ein neues providerspezifisches Setup beizubringen, können Sie die Migrationsoberfläche zentralisieren und die Überprüfungsarbeit auf Modellfreigabe, Observability und Modell-Routing-Richtlinie ausrichten.

Dies erklärt auch, warum die aktuelle Flatkey-Botschaft stärker ist als „es funktioniert mit dem OpenAI SDK“. Der wichtigere Vorteil ist, dass ein OpenAI-kompatibles API-Gateway Zugriff und Überprüfung konsolidieren kann, ohne eine sofortige Überarbeitung der Anwendung zu erzwingen.

Compliance-Formulierungen, die Prüfer freigeben können

Verwenden Sie bei der abschließenden Veröffentlichungsprüfung Formulierungen wie diese:

Vermeiden Sie Formulierungen wie diese, es sei denn, Prüfer können sie belegen:

Diese Einschränkungen machen die Darstellung eines openai compatible api gateway glaubwürdiger, nicht schwächer.

Wann ein OpenAI-kompatibles API-Gateway die richtige Wahl ist

Ein openai compatible api gateway ist in der Regel die richtige Wahl, wenn:

• Ihr Team bereits auf OpenAI-ähnliche Client-Abläufe angewiesen ist und den möglichst wenig störenden Migrationspfad wünscht
• bereits mehr als eine Modellfamilie im Geltungsbereich ist
• Sie einen zentralen Ort benötigen, um Zugriff, Nutzung und genehmigte Routen zu überprüfen
• Modelländerungen häufig genug erfolgen, um eine gemeinsame model routing policy zu rechtfertigen
• Sie eine kontrollierte Migration wünschen, bevor Sie tiefgreifendere Gateway-Funktionen in Betracht ziehen

Wenn diese Bedingungen nicht zutreffen, kann eine direkte Provider-Einrichtung weiterhin einfacher sein. Dieser Artikel sollte diesen Zielkonflikt ehrlich darstellen.

AWS-Teams: Bedrocks OpenAI-kompatible Base URL

Wenn Ihre Modelle auf AWS laufen, stellt Amazon Bedrock seine eigene OpenAI-kompatible Base URL bereit: https://bedrock-runtime.{region}.amazonaws.com/openai/v1, die mit Bedrock-API-Schlüsseln authentifiziert wird. Unser Leitfaden zur OpenAI-kompatiblen API von Amazon Bedrock behandelt Endpunkte, Schlüssel, Modell-IDs und die Einschränkung von /models.

Fazit

Der Wert eines openai compatible api gateway besteht nicht darin, dass es ein neues API-Muster erfindet. Der Wert besteht darin, dass Teams eine vertraute OpenAI-ähnliche Integration beibehalten können, während Zugriff, Modellgenehmigung und Rollout-Kontrolle hinter eine überprüfbare Ebene verlagert werden.

Für Flatkey ist die stärkste überprüfbare Aussage einfach: Behalten Sie das Client-Muster bei, das Sie bereits verwenden, ändern Sie die base URL in https://router.flatkey.ai/v1, validieren Sie den exakt unterstützten Workflow und genehmigen Sie die model routing policy, bevor Sie den Traffic ausweiten. Das ist die Migrationscheckliste, die Entwickler tatsächlich benötigen.