De OpenAI Gateway API uitgelegd in gewone taal

Wat de uitdrukking meestal betekent

Als iemand zoekt naar een openai gateway api, willen ze meestal een van drie dingen, en ze zeggen zelden welke. Het uitzoeken bespaart veel verwarring, omdat de drie verschillende taken en kosten hebben.

Betekenis	Wat het doet	Typische reden om het te willen
Een proxy of router die jij runt	Zit in jouw infrastructuur, accepteert verzoeken in het OpenAI-formaat en stuurt ze door naar een of meer upstream-providers	Centrale sleutels, logging, fallbacks, bestedingsbijhouding per team
Een gehoste service voor meerdere providers	Een derde partij runt die routerlaag voor jou en rekent je daarvoor	Eén account voor veel modellen, geen servers om te onderhouden
Een compatibel endpoint	Een provider serveert zijn eigen model achter hetzelfde verzoek- en responsformaat	Herbruik bestaande SDK-code met een ander model of andere contentregels

Het woord gateway komt uit de netwerk- en API-beheerwereld, waar het een voordeur betekent die referenties controleert, limieten toepast en verkeer doorstuurt. Toegepast op taalmodellen spreekt de voordeur het formaat uit dat populair werd door OpenAI's chat completions endpoint: een JSON body met een modelnaam en een lijst van berichten, een Bearer-token in de header, en een JSON-antwoord met keuzes en tokenverbruik. Omdat er zoveel tools voor dat formaat zijn geschreven, imiteren veel servers het nu.

Waar deze site past

Deze site hoort in de derde rij thuis, niet in de eerste twee. Het is een gehoste API die één open-weight model blootlegt via het OpenAI-verzoekformaat. Het model wordt gerund door een onafhankelijke provider en afgestemd om te antwoorden zonder inhoudelijke weigeringen voor wettelijk volwassen gebruik. Je selecteert het met de model-ID uncensored.

Dat moet worden uitgelegd, omdat de domeinnaam meer zou kunnen suggereren dan het levert:

• Het is niet de officiële API van OpenAI, Meta, Mistral, Qwen, DeepSeek, xAI, Google, Anthropic of een andere leverancier.
• Het is niet een router tussen leveranciers. Geen enkel verzoek wordt doorgestuurd naar het model van een ander bedrijf. Elke call gaat naar hetzelfde model.
• Het is alleen tekst. Er is geen beeld-, audio- of videogeneratie, geen embeddings en geen fine-tuning.
• Het ondersteunt POST /v1/chat/completions en GET /v1/models, en niets meer dan die twee.

Wat je wel krijgt is het vertrouwde oppervlak: streaming via SSE, tool calling, JSON-modus en de gebruikelijke samplingparameters. Het contextvenster is 100.000 tokens, tellend de prompt en het antwoord samen. Details staan in de API-documentatie.

Waarom wire compatibility het nuttige deel is

De meeste waarde van het compatibele-endpoint-idee is dat je switchkosten tot bijna nul dalen. Als je code werkt tegen één OpenAI-achtige server, is het wijzigen van het doel een configuratiewijziging in plaats van een herschrijving. Je verandert een URL en een sleutel, en je verandert de modelnaam.

Zo ziet dat eruit met curl, wat de bewegende delen duidelijk maakt:

Copycurl https://api.openaigatewayapi.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [{"role": "user", "content": "Say hello in three languages."}]
  }'

En hetzelfde via de Python SDK, waar alleen de constructor iets weet van de server:

Copyfrom openai import OpenAI

client = OpenAI(base_url="https://api.openaigatewayapi.com/v1", api_key="paste-your-key-here")

reply = client.chat.completions.create(
    model="uncensored",
    messages=[{"role": "user", "content": "Say hello in three languages."}],
)
print(reply.choices[0].message.content)

Dit is ook waarom een gatewaylaag en een compatibel endpoint door elkaar worden gehaald. Aan de klantzijde zien ze er identiek uit: hetzelfde pad, dezelfde headers, dezelfde JSON. Het verschil zit achter de deur. Een router beslist welk model elk verzoek beantwoordt. Een compatibel endpoint gebruikt altijd het model dat het host.

Wanneer je een echte gatewaylaag nodig hebt

Alleen compatibiliteit geeft je niet de functies die mensen bedoelen als ze het hebben over het runnen van een gateway. Als een van deze van toepassing is op jou, plan dan voor een aparte laag in plaats van te verwachten dat het van één endpoint komt:

• Automatische fallback. Opnieuw proberen bij een andere provider als de eerste een fout geeft.
• Per-team budgetten en sleutels. Geef veel interne sleutels uit, elk met een eigen limiet, vanuit één upstream-account.
• Verzoeklogging en redactie. Registreer prompts en antwoorden centraal, met gevoelige velden verwijderd.
• Routing per taak. Goedkoop model voor classificatie, groter model voor redenering, gekozen door je eigen regels.
• Caching. Retourneer opgeslagen antwoorden voor herhaalde prompts.

Dat zijn goede redenen, en een self-hosted proxy is vaak het juiste antwoord voor een team met meerdere providers. Het voegt ook een service toe om te implementeren, te monitoren en te beveiligen, wat een kostenpost is die makkelijk onderschat wordt voor een klein project. De pagina over de afwegingen van het runnen van een LLM-gateway gaat dat besluit in meer detail door.

De twee ideeën combineren zonder problemen. Een proxy die jij runt kan dit endpoint opnemen als één upstream, met uncensored als het model waar het naartoe stuurt. In die configuratie log je de X-Request-Id response header aan jouw kant. Het is de waarde die je moet opgeven als je ooit hulp nodig hebt bij het traceren van een specifiek verzoek.

Limieten en gedrag waar je op moet anticiperen

Eén gehost endpoint is eenvoudig, maar het heeft randen die je moet kennen voordat je erop bouwt.

Rate- en concurrencylimieten

Een volledige sleutel staat 8 gelijktijdige verzoeken en 300 verzoeken per minuut toe. Een trialsleutel staat 2 gelijktijdige en 60 per minuut toe. Boven de limiet antwoordt de API met HTTP 429 en de error code rate_limited of concurrency. Tijdens tijdelijke overbelasting antwoordt het ook met 429, met een Retry-After: 5 header. Een gestreamd verzoek houdt zijn slot vast tot de stream eindigt, dus lange generaties tellen mee voor concurrency gedurende hun hele duur.

Verzoekgrootte

De maximale body is 8 MB. In de praktijk is het 100.000-tokenvenster de strengere limiet voor de meeste prompts. Als je een lange chatgeschiedenis in elk verzoek stopt, knip het dan voordat je een van beide plafonds raakt.

Observabiliteit

Elk antwoord bevat X-Request-Id en X-Balance-USD, plus headers die je verzoek en concurrencylimieten echoën. Log ze. Een gateway die je later bouwt kan dezelfde headers lezen, dus je verliest niets door ermee te beginnen.

Vragen die je kunt stellen over elke gateway of compatibele API

Dezelfde checklist werkt of je nu deze dienst evalueert, een gehoste router of een self-hosted proxy. Noteer de antwoorden voordat je code schrijft voor een van de opties.

1. Welk model beantwoordt? Een benoemde leverancier, een open-weight model op een onafhankelijke host, of wat de router op dat moment kiest.
2. Wat is de prijs-eenheid? Per token, per verzoek of per maand. Hier is het per token, prepaid.
3. Wat gebeurt er bij een fout? Hier worden mislukte of geweigerde verzoeken niet in rekening gebracht.
4. Welke features zijn echt? Test streaming, tools en JSON-modus met je eigen payloads, niet met een demo-prompt.
5. Waar gaan prompts naartoe? Hier worden ze niet gebruikt voor training. Lees de privacy pagina voor de details en vergelijk deze met een alternatief.
6. Wat zijn de harde limieten? Concurrency, verzoeken per minuut, body-grootte en contextvenster.

Prijzen zijn eenvoudig genoeg om in een minuut te controleren: $0,15 per 1M inputtokens en $0,50 per 1M outputtokens, van prepaidtegoed dat nooit verloopt. De prijzenpagina heeft de opwaardingstiers. Als je wilt zien hoe de endpoint zich gedraagt voordat je iets betaalt, kan de API-sleutelpagina nieuwe gebruikers met één klik een proeftegoed van $0,50 laten claimen, zonder dat een creditcard nodig is.

Een verstandige manier om te beginnen

Houd de eerste test klein. Claim de proefversie, roep GET /v1/models aan om de sleutel te bevestigen, en stuur daarna drie echte prompts vanuit je applicatie met de base URL aangepast. Vergelijk de antwoorden met wat je vandaag krijgt, controleer de response headers en kijk naar de token tellingen in usage. Als de output past en de limieten geschikt zijn voor je verkeer, migreer dan één laag-risico feature voordat je de rest doet. Interne tools, schrijfhulp en achtergrondtaken zijn goede eerste kandidaten, omdat een ruwe rand daar je veel minder kost dan in een customer-facing flow.

Als je later besluit dat je routing of fallbacks nodig hebt, is niets van wat je hebt gebouwd verspeeld. Het requestformaat blijft hetzelfde, en een proxylaag kan voor de endpoint worden toegevoegd zonder dat je applicatiecode hoeft te veranderen.

Meer handleidingen

• OpenAI API voor Ontwikkelaars: Gebruik een Compatibele Endpoint
• OpenAI Gateway API Prijzen: Echte kostenvoorbeelden
• LLM Gateway: Kosten vs. Complexiteitsanalyse