AI Router quickstart: an OpenAI-compatible endpoint
Get an API key, call the endpoint with any OpenAI SDK, and control model routing and spend.
The AI Router is an OpenAI-compatible API gateway. If your code already speaks the OpenAI SDK, changing one base URL and one key is the entire migration.
Create a key
In /panel/ai/router, create an API key. Give it a name that identifies the consumer ("website-chatbot", "staging") so you can revoke precisely later.
Call it
curl:
curl https://ai.hostingswift.example/v1/chat/completions \
-H "Authorization: Bearer $AI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "your-configured-model",
"messages": [{"role": "user", "content": "Explain DNS TTLs in one sentence."}]
}'Python (OpenAI SDK):
from openai import OpenAI
client = OpenAI(api_key="YOUR_KEY", base_url="https://ai.hostingswift.example/v1")
resp = client.chat.completions.create(
model="your-configured-model",
messages=[{"role": "user", "content": "Hello!"}],
)
print(resp.choices[0].message.content)Node (OpenAI SDK):
import OpenAI from 'openai';
const client = new OpenAI({ apiKey: process.env.AI_API_KEY, baseURL: 'https://ai.hostingswift.example/v1' });
const resp = await client.chat.completions.create({
model: 'your-configured-model',
messages: [{ role: 'user', content: 'Hello!' }],
});
console.log(resp.choices[0].message.content);What routing buys you
One endpoint, many models. Switch the upstream model without touching client code.
Spend caps and usage tracking per key.
Failover — if a provider is down, route to another.
Central logging of requests so you can see what your apps actually call.
Rules for using it safely
Never ship a key in client-side code. A key in a browser bundle is public. Proxy through your own server, or use short-lived tokens.
One key per consumer, so leakage is contained and revocation is surgical.
Set spend limits so a runaway loop does not become a surprise invoice.
Rotate keys on a schedule and immediately on suspicion — see API keys and security.
Related reading