One credential, many models, still one approval path.
OpenRouter is useful precisely because it makes switching models easy — which is also the governance problem. NopsAI keeps the choice where it belongs: in a named profile under Git review, scoped to environments, rather than in whatever a step decides at runtime.
OpenRouter inside a governed run.
How OpenRouter participates once it is connected — and what the platform does with what it returns.
A first-class provider
openrouter is one of the nine provider values NopsAI accepts. A profile carries the routed model identifier, such as openai/gpt-4.1-mini, and a credential reference.
Attribution headers supported
The extra map passes provider-specific values such as http_referer and x_title, which is how OpenRouter attributes usage to your application.
Model choice is a config change
Switching the model behind a profile is an edit to system configuration, reviewed and promoted like any other change. Pipelines referencing the profile pick it up without being touched.
Scoped per environment
allowed_scopes decides where a routed profile may be selected, so an experimental model can be available in dev while production stays on an approved one.
The controls that make it safe to leave connected.
An integration is easy to add and hard to bound. These are the parts that decide whether it stays reviewable six months later.
One key, still governed
A single OpenRouter credential could otherwise mean unrestricted model access. Because a pipeline selects a named profile rather than a model string, the breadth of the credential does not become the breadth of what runs can use.
Usage is attributed internally too
AI usage events record the profile and the effective subject, so you can attribute spend to a person and a workflow rather than only to one shared account.
The key is a reference
The API key lives in the encrypted credential registry with versioning, rotation and consumer access logs; configuration holds only the reference URI.
Content boundaries apply first
What may be sent is decided by the pipeline's content sharing settings before any request is constructed, independent of which model the route resolves to.
Owned by Git, reviewed like code.
Configuration is a reviewable file rather than a form someone filled in once. Credentials appear as references; the values live in the encrypted registry.
profiles:
- name: routed
provider: openrouter
model: openai/gpt-4.1-mini
credential_ref: credential://system/llm/openrouter-routed
extra:
http_referer: https://nopsai.example.com
x_title: NopsAI
allowed_scopes: ["dev", "prod"]Workflows where OpenRouter shows up.
The same integration, seen from the workflow rather than from the connection.
Sprint planning for the next two weeks
Planning starts with manual research instead of decisions. Blockers surface late and half-ready stories enter the sprint.
QA is blocked on unclear requirements
QA loses time reconstructing intent. Testing can start from the wrong assumption and clarification cycles cost a day or more.
Monthly status report to leadership
The report takes hours, invites copy-paste mistakes, and is often stale by the time leadership reads it.
What teams ask about OpenRouter.
Can a pipeline pick any OpenRouter model?
No. A pipeline references a profile by name, and the profile fixes the model. Making a different model available is a reviewed configuration change, which is the control a single broad credential would otherwise remove.
How do we stop experimental models reaching production?
Set allowed_scopes on the profile. A profile limited to dev cannot be selected by a run in a production scope.
Is OpenRouter usage visible in NopsAI reporting?
Yes. Usage events are recorded per run with the profile and effective subject, independently of OpenRouter's own dashboard.
Map your OpenRouter workflow end to end.
Bring one real workflow. We will map its trigger, tools, approvals, runtime boundary and evidence requirements with you.