Ingate is an all-in-one AI gateway for enterprise that sits between your applications and LLM providers. It combines a transparent proxy, full observability, prompt versioning, automated evaluations, provider fallback, response caching, guardrails, budget controls, and security governance in a single platform. No SDK required, no code changes needed.

Why use an AI gateway instead of separate tools?

Most AI infrastructure requires stitching together separate tools for observability, prompt management, evaluation, and request routing. Each tool adds its own SDK, configuration, and data silo. An all-in-one gateway like Ingate gives you a single integration point: one base URL change, and you get logging, evals, prompts, caching, guardrails, and budget controls working together. No SDK, no glue code, no data fragmentation.

Does Ingate require an SDK?

No. Ingate works with any HTTP client in any language. Change your base URL to point at Ingate and your existing OpenAI, Anthropic, or custom LLM code works unchanged. Ingate auto-detects the provider from the request path, so most integrations don't even need an extra header. Setup takes under 5 minutes.

What features does Ingate include?

Ingate includes: transparent proxy with SSE streaming, provider fallback, format translation (OpenAI Chat, Responses API, and Anthropic), response caching, PII redaction, prompt injection detection, 14 built-in evaluators, versioned prompt registry, interactive playground, datasets, session tracking, cost tracking, budget controls, audit logging, HMAC-signed webhooks, scoped API keys with rotation, multi-tenant RBAC, REST ingestion API, OpenTelemetry receiver, and Bring Your Own Storage (BYOS).

How does Ingate handle security?

Provider API keys are encrypted with AES-256-GCM at rest. API keys are stored as SHA-256 hashes and never logged. Ingate supports scoped keys with per-provider and per-model restrictions, zero-downtime key rotation, PII redaction on request bodies, prompt injection detection, SSRF protection on outbound requests, and a complete audit log of administrative actions. Auth endpoints are rate-limited to prevent brute-force attacks.

What plans does Ingate offer?

Ingate offers two plans. The Free plan includes the transparent proxy, SSE streaming, request logging, a 7-day retention period, and a built-in dashboard. The Enterprise plan adds prompt versioning, evaluations, datasets, playground, provider fallback, format translation, response caching, PII redaction, guardrails, webhooks, audit log, budget controls, cost tracking, Prometheus metrics, BYOS, custom retention, and a 99.9% uptime SLA.

Providers

Connect any LLM provider to Ingate. Auto-detection routes requests by path, or use explicit headers for full control. Bring your own keys or let Ingate manage them.

Supported Providers

Ingate works with any LLM provider that exposes an HTTP API. Three providers have optimized, built-in implementations with automatic auth header injection:

Provider	Base URL	Auth Header	Auth Format
`openai`	`https://api.openai.com`	`Authorization`	`Bearer {key}`
`anthropic`	`https://api.anthropic.com`	`x-api-key`	`{key}`
`ollama`	`http://localhost:11434`	none	none
Any HTTP endpoint	You configure	Configurable	Configurable

Any HTTP endpoint

Azure OpenAI, Together AI, Fireworks, vLLM, LiteLLM, or your own inference server. If it speaks HTTP, Ingate can route to it. See Custom Providers below.

Adding a Provider

Navigate to Dashboard → Providers → Add Provider. Give your provider a name, set its base URL, and choose an auth mode:

API Key Mode

Ingate encrypts your provider API key with AES-256-GCM and stores it securely. On each request, Ingate decrypts the key and injects it into the upstream request as the correct auth header for that provider. Your client never needs to hold or transmit the provider key.

bash

# Client sends only the Ingate key. Provider key is injected server-side
curl https://api.ingateai.com/v1/chat/completions \
  -H "X-Ingate-Key: sk-ingate-your-key" \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "Hello"}]}'

Auth Passthrough Mode

Ingate does not touch auth headers. Your client's own credentials like OAuth tokens, subscription tokens, session cookies, and passes them through untouched to the upstream provider. Ingate still handles routing, logging, budgets, and guardrails.

bash

# Client sends its own provider credentials. Ingate passes them through.
curl https://api.ingateai.com/v1/chat/completions \
  -H "X-Ingate-Key: sk-ingate-your-key" \
  -H "Authorization: Bearer sk-proj-your-openai-key" \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "Hello"}]}'

When to use each mode

API Key mode: your team shares a single provider key managed by Ingate. Best for centralized billing and key rotation.
Auth Passthrough: each developer or service uses their own provider credentials. Best for subscription-based plans and coding agents.

Auto-Detection

Ingate automatically detects the target provider from the request path. You don't need to set a header for standard API paths:

Request Path	Detected Provider	API
`/v1/chat/completions`	`openai`	Chat Completions
`/v1/completions`	`openai`	Completions (legacy)
`/v1/embeddings`	`openai`	Embeddings
`/v1/models`	`openai`	Model listing
`/v1/responses`	`openai`	Responses API
`/v1/messages`	`anthropic`	Messages
`/api/chat`	`ollama`	Chat
`/api/generate`	`ollama`	Generate

Priority Chain

When Ingate receives a request, it resolves the provider in this order:

Explicit header: X-Ingate-Provider: anthropic always wins
Path auto-detection: matched against the table above
Default provider: the org's configured fallback provider
Error: 400 if no provider can be resolved

bash

# Auto-detected as openai (path: /v1/chat/completions)
curl https://api.ingateai.com/v1/chat/completions \
  -H "X-Ingate-Key: sk-ingate-your-key" \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o-mini", "messages": [{"role": "user", "content": "Hello"}]}'

# Auto-detected as anthropic (path: /v1/messages)
curl https://api.ingateai.com/v1/messages \
  -H "X-Ingate-Key: sk-ingate-your-key" \
  -H "Content-Type: application/json" \
  -d '{"model": "claude-sonnet-4-20250514", "max_tokens": 1024, "messages": [{"role": "user", "content": "Hello"}]}'

# Explicit header overrides auto-detection
curl https://api.ingateai.com/v1/chat/completions \
  -H "X-Ingate-Provider: azure-gpt4" \
  -H "X-Ingate-Key: sk-ingate-your-key" \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "Hello"}]}'

Drop-in replacement

Auto-detection means you can point any OpenAI or Anthropic SDK at https://api.ingateai.com and it just works with no code changes beyond adding the X-Ingate-Key header.

Auth Passthrough

Auth Passthrough is designed for teams where each developer or agent has their own provider credentials (subscription plans, OAuth tokens, or API keys they manage) themselves. Ingate never sees or stores the provider credential.

How it works

Configure the provider in the dashboard with auth mode set to Passthrough
Clients include their own provider auth header alongside X-Ingate-Key
Ingate authenticates the client via X-Ingate-Key, then forwards the request with the client's original auth header intact

Use cases

Scenario	Auth Header Passed Through
Claude Code Pro / Max subscriptions	`x-api-key: sk-ant-...`
Cursor Pro with own OpenAI key	`Authorization: Bearer sk-proj-...`
OAuth-protected inference endpoints	`Authorization: Bearer eyJ...`
Custom internal services with tokens	Any header your service expects

bash

# Developer uses their own Anthropic subscription through Ingate
curl https://api.ingateai.com/v1/messages \
  -H "X-Ingate-Key: sk-ingate-your-key" \
  -H "x-api-key: sk-ant-your-personal-key" \
  -H "Content-Type: application/json" \
  -d '{"model": "claude-sonnet-4-20250514", "max_tokens": 1024, "messages": [{"role": "user", "content": "Hello"}]}'

Ingate features still apply

Even in passthrough mode, Ingate still enforces budgets, guardrails, key scopes, rate limits, and audit logging. You get full observability without touching credentials.

Custom Providers

Any provider beyond the built-in three can be added with full configuration control. Specify auth headers, path prefixes, static query parameters, and extra headers:

Field	Description
`base_url`	Upstream API base URL (required)
`api_key`	Authentication credential (API Key mode only)
`auth_header`	Custom auth header name (default: `Authorization`)
`auth_scheme`	Prefix before the key value (default: `Bearer`)
`path_prefix`	Prepended to every request path
`query_params`	Static query parameters appended to every request
`headers`	Static HTTP headers added to every request

Example: Azure OpenAI

Azure uses a different auth header (api-key), deployment-based paths, and a mandatory api-version query parameter:

Field	Value
Name	`azure-gpt4`
Base URL	`https://myorg.openai.azure.com`
Auth Header	`api-key`
Auth Scheme	(empty, no prefix)
Path Prefix	`/openai/deployments/gpt-4o`
Query Params	`api-version=2024-02-01`

bash

# Request to Azure OpenAI through Ingate
# Ingate builds: https://myorg.openai.azure.com/openai/deployments/gpt-4o/chat/completions?api-version=2024-02-01
curl https://api.ingateai.com/v1/chat/completions \
  -H "X-Ingate-Provider: azure-gpt4" \
  -H "X-Ingate-Key: sk-ingate-your-key" \
  -H "Content-Type: application/json" \
  -d '{"messages": [{"role": "user", "content": "Hello"}]}'

Example: Together AI

bash

# Together AI uses standard Bearer auth with a different base URL
# Name: together
# Base URL: https://api.together.xyz
# Auth Header: Authorization (default)
# Auth Scheme: Bearer (default)

curl https://api.ingateai.com/v1/chat/completions \
  -H "X-Ingate-Provider: together" \
  -H "X-Ingate-Key: sk-ingate-your-key" \
  -H "Content-Type: application/json" \
  -d '{"model": "meta-llama/Llama-3-70b-chat-hf", "messages": [{"role": "user", "content": "Hello"}]}'

Default Provider

One provider can be marked as the default for your organization. The default is used when a request has no X-Ingate-Provider header and the path doesn't match any auto-detection rule.

Set the default in Dashboard → Providers → ⋯ → Set as Default, or via the API:

bash

curl -X PUT https://api.ingateai.com/api/v1/providers/default \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"provider_name": "openai"}'

Resolution order reminder

Explicit header → path auto-detection → default provider → 400 error. The default provider is the last fallback before an error is returned.

Provider Fallback

Enterprise feature

Provider fallback is available on Enterprise plans.

When a primary provider returns a retryable error (429, 500, 502, 503, 504), Ingate automatically retries the request against a configured backup provider. Configure fallback chains in the dashboard under Providers → Fallback.

How it works

Request goes to the primary provider
Primary returns a retryable status code
Ingate retries against the next provider in the fallback chain
Process continues until a provider succeeds or the chain is exhausted

The response includes the X-Ingate-Served-By header showing which provider actually served the request:

bash

# Response header shows which provider handled the request
# X-Ingate-Served-By: anthropic
# (primary was openai, but it returned 429)

Model compatibility

When falling back between providers, ensure the target model exists on the backup provider. Use format translation if the backup uses a different API shape.

Format Translation

Send OpenAI-format requests to Anthropic models. Add the X-Ingate-Translate: true header and Ingate translates the request and response format automatically.

What gets translated

OpenAI messages array → Anthropic messages format
OpenAI system message → Anthropic system parameter
OpenAI response shape → Anthropic response shape (and back)
Token usage fields mapped between formats

bash

# Send OpenAI-format request, Ingate translates to Anthropic format
curl https://api.ingateai.com/v1/chat/completions \
  -H "X-Ingate-Provider: anthropic" \
  -H "X-Ingate-Translate: true" \
  -H "X-Ingate-Key: sk-ingate-your-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-20250514",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Hello"}
    ]
  }'

Combine with fallback

Format translation pairs well with provider fallback. Configure OpenAI as primary and Anthropic as backup with translation enabled. Your clients always send OpenAI-format requests regardless of which provider serves them.