> ## Documentation Index
> Fetch the complete documentation index at: https://omnirelay.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Unified gateway

> What OmniRelay does between your request and the model.

Your application calls one endpoint. OmniRelay authenticates the key, resolves the model inside your workspace, checks that the model is currently available, then meters and records the call.

Reviewed GPT, Claude, DeepSeek and GLM text routes are enabled per workspace. Check your own `GET /v1/models` response for exact IDs with `mode: live`. A catalog entry or successful connection check does not enable a model.

```mermaid theme={null}
flowchart LR
  A[Your app] -->|Bearer key| B[OmniRelay API]
  B --> C{Model active?}
  C -->|yes| D{Model available?}
  D -->|yes| E[Model provider]
  E --> F[Usage + ledger]
  C -->|no| X[404 model_unavailable]
  D -->|no| Y[503 channel_unavailable]
```

## Request lifecycle

**1. Authenticate**

The `Authorization: Bearer` key is hashed and matched against active keys. Revoked keys fail immediately with `401 unauthorized`.

**2. Rate limit**

The key's IP allowlist is checked, then the per-minute and concurrency limits: by default 120 calls per minute and 5 concurrent calls for the whole workspace. See [Rate limits](https://omnirelay.ai/docs/overview/rate-limits.md).

**3. Resolve the model**

The `model` ID must be active in the key's workspace, otherwise the request fails with `404 model_unavailable`.

**4. Check availability**

The model must currently be available for live calls, otherwise `503 channel_unavailable`.

**5. Meter and record**

A live call first reserves a conservative wallet/key budget in an
atomic transaction, before the call is dispatched once. Valid final usage settles
frozen rates and releases the unused hold. An ambiguous result after dispatch
remains pending reconciliation; there is no automatic paid retry or refund.
An insufficient live
reservation budget returns `402` before contacting the provider.

## Live limits

The example below is GPT 5.4 Mini. Most integrated text models allow up to 128,000 output tokens and default to 32,000 (Gemini 3.1 Pro Preview and Gemini 3.6 Flash: at most 65,536); DeepSeek V4 Pro, GLM 5.3 and Kimi K3 default to and allow at most 4,096; GPT 5.4 Mini defaults to 64 and allows at most 256. Check SSE and reasoning support per model. Automatic paid failover is not supported.

`gpt-5.4-mini` supports text/system messages and JSON/SSE responses, with default
64 and maximum 256 output tokens. Reasoning is explicitly `none`. Function tools, JSON object/schema and stateless Responses HTTP/SSE are enabled for GPT 5.4 Mini; strict tools, vision and sampling remain disabled. Physical joint context
is 400,000 tokens. The gateway reserves a request-sized input bound, capped by the
input ceiling, independently of output. The maximum hold depends on current workspace prices and is not the final
fee. Model details label this `provider-context-ceiling` and say the provider checks
context fit. Read [Usage and billing](https://omnirelay.ai/docs/general/usage-billing.md) before enabling
automatic retries in your application.

## Base URLs

| Purpose | URL |
| - | - |
| API | `https://api.omnirelay.ai` |
| OpenAI SDK `base_url` | `https://api.omnirelay.ai/v1` |
| Website and console | `https://omnirelay.ai` |

The API hostname serves only `/v1/*` and `/health`. Every other path returns `404`.

> [!NOTE]
>
> Automatic paid retries and failover are not enabled. New models require capability and billing verification before workspace activation.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.