Other Providers

Observra routes by URL segment, with one dedicated adapter per provider.

For copy-paste code covering raw HTTP, native SDKs, and agent frameworks per language, see Python, PHP, Node.js, Go, .NET, and Java.

Currently supported providers

URL segment	Upstream	Notes
/openai	api.openai.com	Reference integration - see OpenAI SDK Integration
/anthropic	api.anthropic.com	Native Anthropic Messages API protocol supported directly
/groq	api.groq.com	OpenAI-compatible protocol
/gemini	generativelanguage.googleapis.com	Native Gemini protocol; model can be taken from the URL path (/models/{model}:generateContent) instead of the body
/ollama	ollama.com (or your own Ollama host)	NDJSON/JSONL streaming responses
/openrouter	openrouter.ai	OpenAI-compatible protocol
/tokenrouter	api.tokenrouter.com	OpenAI-compatible protocol
/azure	Customer-supplied, via X-Azure-Endpoint header	Azure OpenAI has no fixed upstream base URL - see below
/together	api.together.xyz	OpenAI-compatible protocol
/fireworks	api.fireworks.ai/inference	OpenAI-compatible protocol
/deepseek	api.deepseek.com	OpenAI-compatible protocol
/xai	api.x.ai	OpenAI-compatible protocol
/mistral	api.mistral.ai	OpenAI-compatible protocol
/nim	integrate.api.nvidia.com (or your own self-hosted NIM container)	OpenAI-compatible protocol; provider key is optional (self-hosted NIM often runs with no auth)
/lmstudio	localhost:1234 (or your own LM Studio host)	OpenAI-compatible protocol; provider key is optional (LM Studio runs locally with no auth by default)
/cohere	api.cohere.com	Cohere's own v2 Chat API wire format - translated to/from OpenAI protocol
/huggingface	router.huggingface.co	Hugging Face's unified Inference Providers router - OpenAI-compatible protocol
/vertex	Customer-supplied, via X-Vertex-Endpoint header	Google Cloud Vertex AI - forward your own short-lived GCP OAuth access token as the provider key
/bedrock	Region-derived from X-Aws-Region header	AWS Bedrock's Converse API - requires X-Aws-Access-Key-Id/X-Aws-Region headers plus your AWS secret access key as the provider key; the gateway SigV4-signs the request itself. Streaming is not supported (AWS's binary event-stream framing isn't compatible with the gateway's SSE/NDJSON relay)

Each provider's upstream base URL can be overridden per-deployment via a {PROVIDER}_UPSTREAM_URL environment variable (e.g. OPENAI_UPSTREAM_URL), useful for pointing at a proxy or regional endpoint.

TokenRouter

Use the gateway URL ending at /tokenrouter; the OpenAI SDK adds the chat-completions path:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["OBSERVRA_GATEWAY_KEY"],
    base_url=f'{os.environ["OBSERVRA_GATEWAY_URL"].rstrip("/")}/tokenrouter',
    default_headers={"X-Provider-Key": os.environ["TOKENROUTER_API_KEY"]},
)

response = client.chat.completions.create(
    model="openai/gpt-5",
    messages=[{"role": "user", "content": "Hello"}],
)
print(response.choices[0].message.content)

The equivalent normal HTTP request is:

curl "$OBSERVRA_GATEWAY_URL/tokenrouter/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "X-Gateway-Key: $OBSERVRA_GATEWAY_KEY" \
  -H "X-Provider-Key: $TOKENROUTER_API_KEY" \
  -d '{"model":"openai/gpt-5","messages":[{"role":"user","content":"Hello"}]}'

TokenRouter support currently covers its OpenAI-compatible chat-completions API, including tools and SSE streaming. TokenRouter-specific image, video, Anthropic, Gemini, and Responses API surfaces are not claimed by this adapter.

Cross-protocol calls

Because the gateway detects the incoming client protocol independently of the target provider, you can call a non-OpenAI provider using an OpenAI-shaped request body (or vice versa) and the gateway will translate it - see Routing & Providers for how protocol detection and translation work, and their current limits.

Azure OpenAI specifics

Azure requires an additional X-Azure-Endpoint header carrying your Azure OpenAI resource's https:// endpoint (validated to be an *.openai.azure.com/.azure.us/.azure.eu host) - Azure has no single static upstream URL the way other providers do, since each customer has a dedicated resource endpoint. See Gateway Authentication.

What "supported" means today

Support means: an adapter exists that can build the upstream request and, where cross-protocol translation is needed, translate request/response/streaming-chunk shapes. It does not imply cost data is available for every model on every provider - if Observra doesn't have pricing for a specific model yet, cost is simply left unset for that observation.