Skip to main content
The Gateway is an OpenAI-compatible endpoint that governs LLM traffic in-line — every call is evaluated against your organization’s policies on the way to the provider and on the way back. In Python, the first-party client is the shortest path — one import, no URL or header wiring:
From every other language, call the API directly over plain HTTP (or point any OpenAI-compatible client at https://app.egisai.co/v1/agent with an X-Egis-Api-Key header) — no language requirement: Node, Go, Java, .NET, curl, low-code platforms, and agent builders you don’t control the code of. See the quickstart for ready-made snippets.

​
When to use the Gateway vs. the SDK

They share everything that matters: the same API keys, the same policies, the same agent identities, and the same audit trail. A policy you create once applies to SDK traffic and Gateway traffic alike — Gateway calls appear on the Requests page with a gateway channel marker.
The two are not mutually exclusive. Teams commonly run the SDK in first-party Python services and the Gateway in front of everything else — vendor tools, prototypes, non-Python stacks.

​
Using the SDK through the Gateway

Python teams that want inline, server-side enforcement don’t have to give up the SDK’s ergonomics. Two options:
  • egisai.Client — Egis-first code with a single import: no provider SDK, no base_url, no headers. The client exposes the familiar .chat.completions.create(...) surface and always sends to the Gateway. See Client().
  • egisai.init(gateway=True) — for existing codebases: reroutes the OpenAI client’s chat-completions calls through the Gateway automatically, without touching call sites. See init() → gateway.
In both cases the SDK’s context API keeps working — egisai.set_context(agent=…) and with egisai.agent(…): become the X-Egis-Agent header on the wire, and the other set_context fields (user_id, user_role, session_id, workflow_id, end_user_id) ride along as X-Egis-* context headers so gateway-audited runs show the same Context section as SDK-audited runs — and everything the Gateway doesn’t carry (other providers’ SDKs, agent frameworks, MCP) stays on the in-process governance path, so coverage never drops.

​
How a call flows

1

Your client calls the Gateway

An ordinary chat.completions.create(...) from egisai.Client, or an OpenAI-format POST /v1/agent/chat/completions from any language (base_url=".../v1/agent"; the client appends /chat/completions).
2

Request evaluation

Your organization’s request-phase policies run against the inbound payload. PII is masked before the payload goes anywhere; a block returns immediately (with an OpenAI-shaped error) and the provider is never called.
3

Forward to the provider

The (possibly sanitized) payload is forwarded to the provider. In passthrough mode your Authorization header is forwarded untouched and never stored; in BYOK vault mode the provider key is pulled from the org’s encrypted vault, decrypted in memory for the forward, and never logged.
4

Response evaluation

Response-phase policies run against the completion — assistant text and tool-call requests. A blocked response is replaced with a well-formed stub (finish_reason: "content_filter") so agent loops keep parsing.
5

Audit

The call lands on the dashboard like any SDK call: verdict, matched rules, sanitizations, latency, and token usage — sampled from the post-sanitization state.

​
Connection modes

The Gateway supports two ways to authenticate and supply the provider key. Both use your Egis key to identify the org; they differ only in where the provider key comes from.
  • Passthrough (send provider key). Your provider key rides in Authorization and your Egis key in X-Egis-Api-Key. Zero setup, works out of the box — the default in the SDK and quickstart.
  • Stored key — BYOK vault (no custom headers). Store each provider key once on the dashboard’s Model Center page (encrypted at rest), then send only your Egis key in the Authorization bearer — no custom header, no provider key in the request. The Gateway resolves the right stored key from the request’s model and forwards it upstream. This is what lets platforms that only let you set a base URL and an API key — Cursor, n8n, low-code builders — connect and be governed. With egisai.Client, just omit provider_key.
Provider keys stored in the vault are encrypted at rest (Fernet / AES-128) and only ever decrypted in memory on the forward path — never logged, never returned by the API. The dashboard shows only the last four characters. Managing vault keys is restricted to workspace owners and admins.

​
Keys and headers

Agent identity is otherwise derived automatically from the system prompt, exactly like the SDK — distinct system prompts become distinct agents on the dashboard with no configuration.

​
Providers

The Gateway speaks the OpenAI wire format but is not OpenAI-only: the upstream is chosen per call from the model name. claude-… models are forwarded to Anthropic, gemini-… to Google, mistral-… to Mistral, grok-… to xAI, and deepseek-… to DeepSeek — all through their OpenAI-compatible endpoints — so the same client code works for every provider: change the model and the Authorization key, nothing else. See Limits & behavior for the exact routing table.

​
Native provider formats

Beyond the OpenAI wire format, the Gateway also governs providers in their native shape, so an intercepted SDK needs no rewriting:
  • Anthropic Messages — POST /v1/messages (and /v1/agent/messages).
  • Google generateContent — POST /v1beta/models/{model}:generateContent.
These accept the provider’s own request body, run the same two-phase policy engine, and return refusals in that provider’s error shape so the caller’s SDK raises a typed, catchable error. This is what lets the egress node’s forced-proxy mode forward traffic from any AI app — Claude CLI, native SDKs — to the Gateway untouched.

​
Availability

The Gateway is available on Growth and Enterprise plans. The dashboard’s Gateway page (under Developers) shows connection snippets and live traffic status. Because the Gateway is inline on your traffic, its availability becomes yours — so both sides of the hop have an explicit posture you control:
  • Server-side, if the Gateway can’t read your policies it falls back to the last set it loaded successfully, then to your degraded-mode setting on the Gateway page — refuse the call (503 egis_unavailable, the default) or forward it ungoverned with an X-Egis-Degraded header.
  • Client-side, if you connect through the SDK (init(gateway=True)) and the Gateway can’t be reached at all, the SDK re-runs the call against your own provider client under in-process governance. Set gateway_on_outage="fail" to opt out and keep the Gateway a hard boundary.
Full matrix in Limits & behavior.

​
What’s next

Gateway quickstart

First governed call through the Gateway in two minutes.

Streaming

How stream: true behaves when response-phase rules are active.

Limits & behavior

Error shapes, failure modes, and current limitations.

Policies

The same policies govern SDK and Gateway traffic.