AI & Models · Integration
OpenRouter
Add OpenRouter to your product for your customers, and give your AI agents governed access to it.
OpenRouter is a router in front of many model vendors, so the value is that one request shape reaches hundreds of models and your product does not carry a client per provider. That makes model choice a runtime decision rather than a deploy, which is genuinely useful when a customer wants a specific vendor for policy reasons rather than technical ones. Pricing and availability differ per model and change often, so the model list is worth reading rather than hardcoding. Keys are per account, so a customer bringing their own keeps usage on their bill. Note their terms bar reselling API access, which is exactly why a bring-your-own-key connection is the right shape here rather than proxying through a shared key.
In your product
Embedded for your customers. Per-tenant auth, no per-customer code, maintained by fastn.
Let a customer bring their own OpenRouter key so model usage sits on their account rather than yours.
Reach many providers through one request shape, without a client library per vendor.
Read the live model list with pricing, so a customer chooses rather than accepting your default.
Switch model per customer as a configuration change rather than a release.
For your AI agents
Governed, audited access for the agents you build, through the MCP server.
An agent routes a step to a specific provider a customer's policy requires, with the call audited.
An agent reads current model pricing before choosing which to use for a bulk job.
An agent falls back to another provider when one is unavailable, within governed permissions.
Example prompt
Which available models can handle this context length, and what would this job cost on each?
Set up OpenRouter in 4 steps
- 01Enable the OpenRouter connector from your fastn dashboard.
- 02Have each customer authorise their own OpenRouter account, so calls run under their credentials rather than a shared key.
- 03Decide which models, requests and outputs your product needs, map those fields, then enable the actions and triggers you want.
- 04Call it from your product and expose it to your agents through the same governed connection.
Why teams use the OpenRouter integration
What you get by embedding it with fastn instead of building it yourself.
- Ship an OpenRouter integration without building it. Your customers connect their own OpenRouter account inside your product and work their models, requests and outputs there, with no per-customer code on your side.
- Handle the part that actually costs time: per-customer keys, quotas and cost attribution matter more than schema here, because every call is billed. fastn owns the auth, token refresh, rate limits, pagination and breaking-change fixes, so an OpenRouter update is not your on-call problem.
- One integration serves your product and your agents. The same governed OpenRouter connection powers in-product features and gives AI agents scoped, audited access, so you give your product and your agents a model call each customer pays for themselves without wiring it twice.
Used by these teams
Compare with
OpenAI
Mistral AI
Anthropic ClaudeOften used alongside
Tools the same teams tend to run next to OpenRouter, across other categories.
Snowflake
Airtable
PostgreSQL
AmplitudeOpenRouter integration FAQ
How do I add an OpenRouter integration to my product?
Enable the OpenRouter connector in your fastn dashboard, then let each customer authenticate their own OpenRouter account. fastn handles the OAuth flow, token storage and refresh per tenant, so there is no OpenRouter client code in your app and no per-customer branch in your codebase. Setup is 4 steps.
Do my customers each connect their own OpenRouter account?
Yes. Every connection is scoped to the individual customer, so each authorises their own OpenRouter account and only ever sees their own models, requests and outputs. That per-tenant isolation is the point of an embedded integration: you support the long tail of customer setups without maintaining an integration per customer.
Can AI agents use this OpenRouter integration?
Yes. The same connection is exposed to your agents through the fastn MCP gateway, with permissions scoped per tenant and every call audited. An agent routes a step to a specific provider a customer's policy requires, with the call audited.
Who maintains the OpenRouter integration?
fastn does. When OpenRouter changes an endpoint, deprecates a field or alters its auth, the fix lands in the connector rather than in your backlog, and your customers' connections keep working.
Whose OpenRouter API key and quota does each call use?
Each customer authorises their own OpenRouter account, so usage, rate limits and cost land on the customer that caused them. You are not metering a shared key and re-billing it, and one heavy customer cannot exhaust another's quota.
Are inputs and outputs auditable?
Yes. Every call is logged per tenant with the call, the input and the result, so an output can be traced back to what produced it. That matters more here than in most integrations, because a generated answer or an extracted field cannot be reconstructed from the request alone.
What can I build with the OpenRouter integration?
A common starting point: let a customer bring their own OpenRouter key so model usage sits on their account rather than yours. Teams also use it for the other use cases listed above, and expose it to agents for governed reads and writes.
How much does the OpenRouter integration cost?
It is included. Pricing is based on connected accounts, not on how many connectors you enable, so adding OpenRouter does not change your per-connector cost. You can start free with 3 connected accounts.
Add OpenRouter to your product
Start free with 3 connected accounts. No sales call required, and no per-customer integration code.