Run your API relay station on one managed upstream channel
An API relay station aggregates upstream channels behind relay software — usually one-api or new-api — and serves models to your own users under your own accounts and pricing. Router One slots in as one OpenAI-compatible channel that reaches 30+ models (GPT, Claude, Gemini, Grok): one base URL, one API key, no per-provider account juggling. Requests are served by the model you name; a failing route (429, 5xx, timeout) is retried on another route for the same model, and routes with a sustained upstream-error rate are automatically moved to the back of the order until they recover. Only model: "auto" lets the gateway pick the model, by sorting each request into a low, medium or high tier. The pay-as-you-go token line uses posted model rates, with checkout-visible FX/channel fees kept separate — what you charge your downstream users stays your call.
Add Router One as a channel in one-api / new-api
Both one-api and new-api take the same three inputs for an OpenAI-compatible channel: the base URL, an API key, and the model IDs the channel should serve. Create a dedicated key for the relay (with its own maxSpend budget so the whole station's wallet charges have a hard ceiling), paste the host shown below as the channel base URL when the channel type is OpenAI — without a trailing /v1, because one-api and new-api append the /v1/chat/completions path themselves and a doubled /v1 turns into a 404; one-api's separate OpenAI-compatible channel type instead takes the /v1 base URL, because it strips /v1 from the request path before appending /chat/completions — then copy exact model IDs from the /models page — IDs are case-sensitive and the page lists live per-token rates next to each one.
# Channel settings in one-api / new-api Base URL: https://api.router.one (channel type "OpenAI": one-api / new-api append /v1/chat/completions) (one-api's separate "OpenAI 兼容" channel type wants https://api.router.one/v1)
One Router One channel vs a rack of provider-direct channels
| Running the station | One Router One channel | Provider-direct channels |
|---|---|---|
| Models behind one channel | 30+ models across GPT, Claude, Gemini, Grok families | One family per account; every provider is another channel to babysit |
| Retry behavior upstream | Same-model failover with automatic demotion of failing routes, managed | You script retries channel by channel |
| Per-request visibility | Trace per request: model, tokens, cost, latency, status | Whatever each provider's console exposes |
| Spend ceiling per channel | The channel's key carries its own maxSpend budget | Account-wide billing, capped after the bill arrives |
| Billing and top-up | One wallet — card or Alipay via hosted checkout, or USDT/USDC on six chains | Separate billing per provider account |
| Reachable from mainland China | Direct connectivity, no VPN required | Varies by provider |
Cap each downstream group before it caps you
Relay software already meters your users — Router One meters the upstream side. Issue a separate key per relay instance, user group, or resold tier; each key's maxSpend puts a hard ceiling on what any single group can charge to your wallet, and rate limits follow platform defaults that can be raised on request. When a downstream user disputes a charge, the per-request trace (model, tokens, cost, latency, status) is the receipt you reconcile against.
The relay operator's credibility problem: is it the real model?
Every relay station lives or dies on one question from its users: am I getting the model I paid for? On Router One the model you request is the model served — no silent downgrades or substitutions — and every response is backed by a per-request trace you can show. Router One does not retain prompt or model-response bodies from direct API calls. It records request metadata for billing, usage tracking, and troubleshooting. Playground saves conversation history so users can revisit and continue their chats.
How to verify you get the real modelFAQ
How do I add Router One as a channel in one-api or new-api?
Create a channel of type OpenAI, set the base URL to the host shown above (no trailing /v1 — the relay builds the /v1 path itself; if you pick one-api's separate OpenAI-compatible channel type, use the /v1 base URL instead), paste an API key created for the relay, and list the model IDs you want the channel to serve (copy them exactly from /models — they are case-sensitive). Assign the channel to your groups and it starts serving.
My buyers run Claude Code. How do I set up the channel in new-api?
Add a second channel of the Claude type with the base URL https://api.router.one, the host root, because new-api's Claude channel appends /v1/messages itself. It sends your Router One key as x-api-key, passes the client's anthropic-beta header through, and keeps ?beta=true when the incoming request carried it (Claude Code calls /v1/messages?beta=true) or when the channel's Claude beta-query setting is on. List only Claude and DeepSeek V4 model IDs on this channel: those are the models Router One serves on /v1/messages. Your buyers then point ANTHROPIC_BASE_URL at your relay.
My buyers run Codex CLI. What does the relay need?
Codex speaks the Responses API, and new-api's OpenAI channel forwards /v1/responses as it arrives, so the OpenAI-type channel above (host-root base URL) serves it. For Codex, list GPT-family, DeepSeek V4 and Grok chat IDs, the models Router One serves on /v1/responses; a Claude ID sent there gets a 400 that names /v1/messages or /v1/chat/completions. One gap to state plainly: Router One has no /v1/responses/compact route, so compaction requests forwarded through the channel return 404. one-api's repository has not been updated since 2026-01-09 and its Responses support is unverified, so check your version before you offer Codex to buyers.
Which models can one channel serve?
30+ models from the live catalog — GPT, Claude, Gemini, and Grok families — through the single OpenAI-compatible endpoint. The /models page is the authoritative line-up with per-token rates.
How do I stop one downstream group from draining the wallet?
Give each relay instance or user group its own key. Each key carries its own maxSpend budget (rate limits follow platform defaults and can be raised on request), so the blast radius of any runaway group is the key's ceiling, not your balance.
How do I monitor the upstream balance so the station never runs dry?
Poll GET https://api.router.one/v1/balance from your server with a key of the account. It returns balance, reserved_balance and total_balance in USD, live, under its own limit of 60 requests per minute that does not draw on the channel's inference limits. Alert on balance and top up in the dashboard before it empties, because an empty wallet answers every key's wallet-billed requests with HTTP 402. The channel balance lookup built into one-api and new-api calls OpenAI's legacy /v1/dashboard/billing paths, which Router One does not serve, so run a small cron instead; the balance monitoring guide (/blog/llm-api-balance-monitoring) has the scripts.
Can I run a relay from mainland China without a VPN?
Router One is reachable directly from mainland China, so a relay hosted there can call the endpoint without a VPN. Wallet top-ups work with a card or Alipay through one hosted checkout, or with USDT/USDC on six chains.
Does Router One add markup to the rates my station pays?
The pay-as-you-go token line uses posted model rates, with checkout-visible FX/channel fees kept separate. Your downstream pricing — and the spread you keep — is set in your own relay, not by Router One.
Related
- LLM API reseller
- White-label LLM API
- Wholesale LLM API
- LLM API authenticity
- LLM observability
- OpenRouter alternative
- Model catalog & rates
- LLM gateway vs API relay: 5 differences
Point your relay at one upstream channel
Get your API key