OpenAI Gateway API Explained in Plain Terms

What the phrase usually means

When someone searches for an openai gateway api, they usually want one of three things, and they rarely say which. Sorting them out first saves a lot of confusion, because the three have different jobs and different costs.

Meaning	What it does	Typical reason to want it
A proxy or router you run	Sits in your infrastructure, takes requests in the OpenAI format and forwards them to one or more upstream providers	Central keys, logging, fallbacks, spend tracking per team
A hosted multi-provider service	A third party runs that routing layer for you and bills you for it	One account for many models, no servers to maintain
A compatible endpoint	A provider serves its own model behind the same request and response format	Reuse existing SDK code with a different model or different content rules

The word gateway comes from networking and API management, where it means a front door that checks credentials, applies limits and passes traffic along. Applied to language models, the front door speaks the format popularized by OpenAI's chat completions endpoint: a JSON body with a model name and a list of messages, a bearer token in the header, and a JSON answer with choices and token usage. Because so many tools were written for that format, plenty of servers now imitate it.

Where this site fits

This site belongs in the third row, not the first two. It is a hosted API that exposes one open-weight model through the OpenAI request format. The model is run by an independent provider and tuned to answer without content refusals for lawful adult use. You select it with the model ID uncensored.

That needs spelling out, because the domain name could suggest more than it delivers:

• It is not the official API of OpenAI, Meta, Mistral, Qwen, DeepSeek, xAI, Google, Anthropic or any other vendor.
• It is not a router across vendors. No request is sent on to another company's model. Every call goes to the same model.
• It is text only. There is no image, audio or video generation, no embeddings and no fine-tuning.
• It supports POST /v1/chat/completions and GET /v1/models, and nothing beyond those two.

What you do get is the familiar surface: streaming over SSE, tool calling, JSON mode, and the usual sampling parameters. The context window is 100,000 tokens, counting the prompt and the completion together. Details are in the API documentation.

Why wire compatibility is the useful part

Most of the value in the compatible-endpoint idea is that your switching cost drops to nearly nothing. If your code works against one OpenAI-style server, pointing it at another is a configuration change instead of a rewrite. You change a URL and a key, and you change the model name.

Here is what that looks like with curl, which makes the moving parts easy to see:

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

And the same thing through the Python SDK, where only the constructor knows about the 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)

This is also why a gateway layer and a compatible endpoint get mixed up. From the client side they look identical: same path, same headers, same JSON. The difference is behind the door. A router decides which model answers each request. A compatible endpoint always uses the model it hosts.

When you need a real gateway layer

Compatibility alone does not give you the features people mean when they talk about running a gateway. If any of these apply to you, plan for a separate layer rather than expecting it from a single endpoint:

• Automatic fallback. Retry on another provider when the first one errors out.
• Per-team budgets and keys. Issue many internal keys, each with its own cap, from one upstream account.
• Request logging and redaction. Record prompts and responses centrally, with sensitive fields removed.
• Routing by task. Cheap model for classification, larger model for reasoning, chosen by your own rules.
• Caching. Return stored answers for repeated prompts.

Those are good reasons, and a self-hosted proxy is often the right answer for a team with several providers. It also adds a service to deploy, monitor and secure, which is a cost that is easy to underestimate for a small project. The page on the trade-offs of running an LLM gateway goes through that decision in more detail.

The two ideas combine without trouble. A proxy you run can list this endpoint as one upstream, with uncensored as the model it forwards to. In that setup, log the X-Request-Id response header on your side. It is the value to quote if you ever need help tracing a specific call.

Limits and behavior you should plan for

A single hosted endpoint is simple, but it has edges you should know about before you build on it.

Rate and concurrency caps

A full key allows 8 concurrent requests and 300 requests per minute. A trial key allows 2 concurrent and 60 per minute. Over the line, the API answers HTTP 429 with the error code rate_limited or concurrency. During temporary overload it also answers 429, with a Retry-After: 5 header. A streamed request keeps its slot until the stream ends, so long generations count against concurrency for their whole duration.

Request size

The maximum body is 8 MB. In practice the 100,000-token window is the tighter limit for most prompts. If you stuff a long chat history into every call, trim it before you hit either ceiling.

Observability

Every response includes X-Request-Id and X-Balance-USD, plus headers that echo your request and concurrency limits. Log them. A gateway you build later can read the same headers, so you lose nothing by starting with them.

Questions to ask about any gateway or compatible API

The same checklist works whether you evaluate this service, a hosted router or a self-hosted proxy. Write the answers down before you commit code to any of them.

1. Whose model answers? A named vendor, an open-weight model on an independent host, or whatever the router picks that minute.
2. What is the price unit? Per token, per request, or per month. Here it is per token, prepaid.
3. What happens on failure? Here, failed or refused requests are not charged.
4. Which features are real? Test streaming, tools and JSON mode with your own payloads, not a demo prompt.
5. Where do prompts go? Here they are not used for training. Read the privacy page for the details and compare it with any alternative.
6. What are the hard limits? Concurrency, requests per minute, body size and context window.

Pricing is simple enough to check in a minute: $0.15 per 1M input tokens and $0.50 per 1M output tokens, from prepaid credit that never expires. The pricing page has the top-up tiers. If you want to see how the endpoint behaves before paying anything, the API key page lets new users claim a $0.50 trial credit with one click, with no card needed.

A sensible way to start

Keep the first test small. Claim the trial, call GET /v1/models to confirm the key, then send three real prompts from your application with the base URL changed. Compare the answers with what you get today, check the response headers, and look at the token counts in usage. If the output fits and the limits suit your traffic, move one low-risk feature over before the rest. Internal tools, drafting helpers and background jobs make good first candidates, since a rough edge there costs you far less than one in a customer-facing flow.

If you later decide you need routing or fallbacks, nothing you built is wasted. The request format stays the same, and a proxy layer can be added in front without changing application code.

More guides

• OpenAI API for Developers: Use a Compatible Endpoint
• OpenAI Gateway API Pricing: Real Cost Examples
• LLM Gateway: Cost vs. Complexity Analysis