DEVELOPERS

A familiar API, with governance behind it.

Point an OpenAI client at Octoryn Router and keep the request patterns your team already uses. The interface feels familiar; the routing policy is built for Octopus customers and family products.

01/v1OpenAI-compatible API entrypoint

02SSEStreaming response pattern

03policy/*Stable, governed routing aliases

Change the base URL, not the application.

Use the OpenAI SDK and direct its base URL to the Octoryn endpoint. Applications can request an eligible model or a stable policy alias without importing product code into the Router.

Base URL: https://api.octoryn.dev/v1Expand details
This is part of Change the base URL, not the application.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs
Send familiar chat completion request shapesExpand details
This is part of Change the base URL, not the application.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs
Keep product and routing deployments independentExpand details
This is part of Change the base URL, not the application.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs

Stream through the same client workflow.

Streaming requests follow the OpenAI-compatible client pattern, so applications can process incremental output without adopting a Router-specific application framework.

Enable streaming in the SDK requestExpand details
This is part of Stream through the same client workflow.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs
Consume incremental events in the clientExpand details
This is part of Stream through the same client workflow.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs
Handle disconnects and cancellation at the application boundaryExpand details
This is part of Stream through the same client workflow.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs

Carry tools and structured output deliberately.

Tool calls and structured-output fields can travel through the compatible request surface when the selected upstream model supports them. Applications should still validate arguments and outputs before execution.

Describe tools with the SDK request formatExpand details
This is part of Carry tools and structured output deliberately.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs
Select a model or policy appropriate to the capabilityExpand details
This is part of Carry tools and structured output deliberately.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs
Validate schemas and tool arguments in your applicationExpand details
This is part of Carry tools and structured output deliberately.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs

Design failures as part of the contract.

Treat rate limits, provider failures and timeouts as normal distributed-system outcomes. Use bounded retries with backoff where requests are safe to repeat, and log the routing and response metadata made available to your client.

Handle 429 and 5xx responses explicitlyExpand details
This is part of Design failures as part of the contract.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs
Apply bounded backoff and application-level timeoutsExpand details
This is part of Design failures as part of the contract.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs
Record latency, status and request correlation data when availableExpand details
This is part of Design failures as part of the contract.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs

OpenRouter-style access, Octoryn operating policy.

Like OpenRouter, Octoryn offers a portable model access layer behind one compatible interface. The difference is its operating context: centrally governed routes for Octopus customers and family products, with product systems calling the Router as an independent service.

Keep providers replaceable behind stable aliasesExpand details
This is part of OpenRouter-style access, Octoryn operating policy.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs
Apply customer and product policy before provider dispatchExpand details
This is part of OpenRouter-style access, Octoryn operating policy.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs
Avoid reverse imports from the Router into product applicationsExpand details
This is part of OpenRouter-style access, Octoryn operating policy.. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
View implementation docs

OCTORYN ROUTER

Start with the client you already know.

Use the developer documentation for request examples and confirm model-specific capability support before production rollout.

Open developer docs