Routing
How OffRail selects an eligible upstream route while preserving one public API contract.
Routing
Send a public model ID to its documented endpoint. OffRail authenticates the request, selects an eligible upstream route, meters usage, and returns the documented result shape.
Browse the public model catalogue or retrieve the
current list through GET /v1/models.
Model routing
Use the model ID without a provider prefix:
curl "https://api.offrail.ai/v1/chat/completions" \
-H "Authorization: Bearer $OFFRAIL_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "glm-5.2-fast",
"messages": [{"role": "user", "content": "Write the next scene."}]
}'The public model ID is the stable part of your integration. Provider selection remains behind the gateway.
Eligible fallback
When the selected upstream route fails before a usable result is returned, OffRail may retry another compatible route. A fallback is only considered when the next route supports the same request capabilities.
OffRail does not retry invalid client requests as provider failures. Fix 4xx
validation errors before resending the request.
Delivery behavior
| Generation type | Delivery |
|---|---|
| Chat | JSON or streamed events |
| Image | Result or task response, depending on the model |
| Video | Asynchronous task with retrieval and content endpoints |
| Audio | Audio response |
See the relevant model page for its endpoint, billing unit, input requirements, and output contract.
Provider pinning
The first public preview documents model-level routing. Provider-specific pages, custom routing policies, and user-supplied provider keys are not part of this release surface.
Use the public model ID unless OffRail support explicitly gives you a provider-specific route for an integration test.
Errors and timeouts
Routing failures use the standard error envelope. See Error Handling and Request Timeouts for the response behavior your client should implement.