Routing & Provider Config
Overview
The config endpoints let you programmatically inspect and update how MultiRoute routes requests across providers and models. This is useful for:
- Managing routing rules and model preferences as code.
- Automating rollout of new models or providers.
- Tuning fallback behavior and timeouts without redeploying your backend.
Configuration operations are more sensitive than regular inference calls and may require elevated permissions or JWT-based authentication.
Endpoint summary
Typical operations include:
| Method | Path | Description |
|---|---|---|
GET |
/v1/config |
Retrieve the current effective configuration. |
POST |
/v1/config |
Update configuration (partial or full). |
Exact shape and available fields may vary depending on how your MultiRoute account or workspace is set up, but the patterns below illustrate a typical contract.
Authentication
Config endpoints require authentication. By default, they accept:
- An API key with sufficient privileges:
Authorization: Bearer <your-api-key>
- Or a JWT access token issued via the MultiRoute auth flow:
Authorization: Bearer <access-token>
See Authentication for more details on roles, scopes, and token management.
GET /v1/config
Retrieve the current routing and provider configuration for the authenticated account or workspace.
- Method:
GET - Path:
/v1/config
Example response
{
"default_model": "multiroute-chat-latest",
"routes": {
"chat": {
"primary": "provider-a:gpt-4.1",
"fallbacks": [
"provider-b:chat-1",
"provider-c:chat-pro"
],
"timeout_ms": 20000
},
"images": {
"primary": "provider-d:image-1",
"timeout_ms": 30000
}
},
"limits": {
"max_tokens": 4096
}
}
The concrete keys and structure are implementation-specific, but the response typically includes:
- Default model or route names.
- Per-endpoint routing settings (primary, fallbacks, timeouts).
- Global or per-route limits and policies.
POST /v1/config
Update routing and provider configuration. Depending on your setup, updates may be:
- Partial merges: Only specified fields are updated.
- Full replacements: The provided document replaces the existing configuration.
Check with your account or workspace settings to confirm the exact behavior.
- Method:
POST - Path:
/v1/config
Example request (partial update)
curl https://api.multiroute.ai/v1/config \
-H "Authorization: Bearer $MULTIROUTE_ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"routes": {
"chat": {
"primary": "provider-b:chat-1",
"fallbacks": ["provider-a:gpt-4.1"],
"timeout_ms": 25000
}
}
}'
Example request body
{
"routes": {
"chat": {
"primary": "provider-b:chat-1",
"fallbacks": [
"provider-a:gpt-4.1"
],
"timeout_ms": 25000
}
}
}
Example response
{
"status": "ok",
"config": {
"default_model": "multiroute-chat-latest",
"routes": {
"chat": {
"primary": "provider-b:chat-1",
"fallbacks": [
"provider-a:gpt-4.1"
],
"timeout_ms": 25000
}
}
}
}
Best practices
- Use admin-scoped credentials: Restrict config updates to admin roles or CI/CD pipelines with dedicated tokens.
- Version your configuration: Store config JSON or YAML in git and treat it like infrastructure-as-code.
- Roll out gradually: When changing routing for critical workloads, consider phased rollouts or canary environments.
- Monitor errors and latency: After config changes, watch for spikes in error rates or latency across providers.