Provider Integration
For Providers
If you’d like to be a model provider and sell inference on OpenRouter, fill out our form to get started.
To be eligible to provide inference on OpenRouter you must have the following:
1. List Models Endpoint
You must implement an endpoint that returns all models that should be served by OpenRouter. At this endpoint, please return a list of all available models on your platform. Below is an example of the response format:
NOTE: pricing fields are in string format to avoid floating point precision issues, and must be in USD.
Valid quantization values are: int4, int8, fp4, fp6, fp8, fp16, bf16, fp32.
Valid sampling parameters are: temperature, top_p, top_k, repetition_penalty, frequency_penalty, presence_penalty, stop, seed.
Valid features are: tools, json_mode, structured_outputs, web_search, reasoning.
Tiered Pricing
For models with different pricing based on context length (e.g., long context pricing), you can provide pricing as an array of tiers instead of a single object:
When using tiered pricing, the first tier (index 0) is the base pricing that applies when input tokens are below the min_context threshold. The second tier applies when input tokens meet or exceed the min_context value.
Limitations:
- Currently, OpenRouter supports up to 2 pricing tiers.
- The
imageandrequestfields are only supported in the base tier (index 0) and will be ignored if included in other tiers.
2. Auto Top Up or Invoicing
For OpenRouter to use the provider we must be able to pay for inference automatically. This can be done via auto top up or invoicing.
3. Uptime Monitoring & Traffic Routing
OpenRouter automatically monitors provider reliability and adjusts traffic routing based on uptime metrics. Your endpoint’s uptime is calculated as: successful requests ÷ total requests (excluding user errors).
Errors that affect your uptime:
- Authentication issues (401)
- Payment failures (402)
- Model not found (404)
- All server errors (500+)
- Mid-stream errors
- Successful requests with error finish reasons
Errors that DON’T affect uptime:
- Bad requests (400) - user input errors
- Oversized payloads (413) - user input errors
- Rate limiting (429) - tracked separately
- Geographic restrictions (403) - tracked separately
Traffic routing thresholds:
- Minimum data: 100+ requests required before uptime calculation begins
- Normal routing: 95%+ uptime
- Degraded status: 80-94% uptime → receives lower priority
- Down status: <80% uptime → only used as fallback
This system ensures traffic automatically flows to the most reliable providers while giving temporary issues time to resolve.
4. Performance Metrics
OpenRouter publicly tracks TTFT (time to first token) and throughput (tokens/second) for all providers on each model page.
Throughput is calculated as: output tokens ÷ generation time, where generation time includes fetch latency (time from request to first server response), TTFT, and streaming time. This means any queueing on your end will show up in your throughput metrics.
To keep your metrics competitive:
- Return early 429s if under load, rather than queueing requests
- Stream tokens as soon as they’re available
- If processing takes time (e.g. reasoning models), send SSE comments as keep-alives so we know you’re still working on the request. Otherwise we may cancel with a fetch timeout and fallback to another provider