Guides
Two ways to add a model to your catalog: bring your own provider key to serve a catalog model on your own account, or register your own OpenAI-compatible server.
In the web app, open /models and click Add model. You'll be asked which kind you're adding:
On a model's own page, the same two paths live under Add your own key or local model in the waterfall.
A BYOK route serves a catalog model on your own provider account: you connect the provider's key once, and that model gains a customer_managed pass-through route the gateway can use. The provider bills you directly and the gateway adds no markup. Connecting a key is free on any plan.
The fastest path is Add model → Add an API key: search the catalog, pick the model, and you land on its page with the key form open. Connecting or rotating a key is a single upsert; verify it with a check call. Keys are write-only — reads never return secret material, only the last four characters.
curl -X PUT "https://api-pr-1501.preview.experientiallabs.ai/api/orgs/$ORG_ID/provider-connections/openai" \-H "Authorization: Bearer $EXPLABS_API_KEY" \-H "Content-Type: application/json" \-d '{"secret": "sk-...", "config": {}}'# Verify itcurl -X POST "https://api-pr-1501.preview.experientiallabs.ai/api/orgs/$ORG_ID/provider-connections/openai/check" \-H "Authorization: Bearer $EXPLABS_API_KEY"
Each provider is connected differently:
| provider | A connection needs |
|---|---|
| openai | An API key (sk-...). |
| anthropic | An API key. |
| gemini | An API key. |
| openrouter | An API key. |
| fireworks | An API key (and account id). |
| azure_openai | A key, the resource endpoint, an api_version, and a model-to-deployment map. |
| bedrock | AWS credentials and a region. |
| vertex | A service-account JSON key, the GCP project id, and the Vertex location. |
| modal | A base_url and a Modal token pair. |
A local model is your own OpenAI-compatible server (a self-hosted vLLM box, a lab server) registered as an ordinary catalog row scoped to your org: one model plus a local deployment pointing at your server's base_url. It becomes callable by slug just like a hosted model, private to your organization, with identical telemetry. Adding a local model is a Pro feature.
In the app, use Add model → Add a local model. Set a name, the base URL, and the model id your server expects. The Supported parameters you check (temperature, tools, reasoning, response format, structured outputs) are recorded on the route, so the gateway accepts exactly those fields and rejects the rest — declare what your server actually supports. If your server requires a key, pass endpoint_api_key and the gateway sends it as the Bearer token on every request; it is stored encrypted and never echoed back. Rotate or clear it with PUT /api/models/<slug>/providers/<id>/endpoint-credential.
curl -X POST "https://api-pr-1501.preview.experientiallabs.ai/api/models" \-H "Authorization: Bearer $EXPLABS_API_KEY" \-H "Content-Type: application/json" \-d '{"slug": "my-local-model","display_name": "My Local Model","supported_params": {"temperature": true, "tools": true},"providers": [{"provider": "local","provider_model_id": "my-model","base_url": "https://your-host:8000/v1","endpoint_api_key": "the-key-your-server-requires"}]}'
To add another way to reach an existing model (a local variant, a second provider), post a deployment to POST /api/models/<slug>/providers, then add it to the waterfall.
Models covers the catalog, provider waterfalls, and the two payment lanes; Errors covers what an unsupported field or a failed route returns.