PROVIDER ABSTRACTION

One governed contract for eligible model supply.

Octoryn separates application code from provider-specific endpoints. Teams define which supply is eligible, bring authorised credentials where required, and route through stable policies without exposing provider mechanics to every product.

011 APIapplication-facing contract

02BYOKauthorised customer credentials

03Policyprovider eligibility controls

04Portablesupply without code coupling

Abstract provider mechanics at the Router boundary

Products integrate once with Octoryn’s OpenAI-compatible surface. Provider authentication, request translation and operational differences remain behind the routing boundary.

A consistent request and response contractExpand details
This is part of Abstract provider mechanics at the Router boundary. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
Provider-specific concerns kept out of product repositoriesExpand details
This is part of Abstract provider mechanics at the Router boundary. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
Stable policy aliases instead of hard-coded model endpointsExpand details
This is part of Abstract provider mechanics at the Router boundary. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
A clear boundary between product teams and model supplyExpand details
This is part of Abstract provider mechanics at the Router boundary. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls

Eligibility is explicit, not accidental

A provider route is considered only when it satisfies the workload’s policy. Region, data handling, capability, environment and commercial authorisation can all constrain the eligible set.

Allow and deny rules by workload or environmentExpand details
This is part of Eligibility is explicit, not accidental. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
Capability and regional eligibility checksExpand details
This is part of Eligibility is explicit, not accidental. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
Data-handling requirements applied before selectionExpand details
This is part of Eligibility is explicit, not accidental. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
Controlled fallback among eligible routes onlyExpand details
This is part of Eligibility is explicit, not accidental. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls

BYOK without credentials in application code

Customer-owned access can be attached to governed routes while secrets remain isolated from calling products. Ownership does not bypass policy, budgets or audit controls.

Credentials separated by customer and environmentExpand details
This is part of BYOK without credentials in application code. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
Workload roles instead of embedded secretsExpand details
This is part of BYOK without credentials in application code. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
Usage attributed to the authorised routeExpand details
This is part of BYOK without credentials in application code. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
Rotation without a product releaseExpand details
This is part of BYOK without credentials in application code. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls

Change supply through reviewable policy

Adding or replacing supply is an operational decision. Candidate routes are evaluated, reviewed and promoted behind stable aliases so product teams retain a dependable contract.

Pre-production evaluation before eligibilityExpand details
This is part of Change supply through reviewable policy. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
Policy versions and auditable changesExpand details
This is part of Change supply through reviewable policy. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
Health-aware routing and bounded fallbacksExpand details
This is part of Change supply through reviewable policy. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls
Rollback without changing application integrationsExpand details
This is part of Change supply through reviewable policy. Octoryn keeps its configuration, outcome and routing context together so teams can validate and review the capability independently.
Explore related controls

OCTORYN ROUTER

Define the supply boundary once.

Describe the workload, authorised access and operating constraints. Octoryn turns them into a governed provider policy.

Open developer docs