There is a small but real business in packaging LLM access for people who don't want to manage it themselves: agencies bundling AI features into client projects, consultants running workloads for several customers, builders selling a niche tool with model calls inside. Most "how to resell AI APIs" content either oversells what's possible or quietly assumes you'll run a gray-market relay. This post does neither.
Here is the honest version: what you can build today on key-level controls over a managed upstream, how the economics work, and — just as important — what this pattern does not give you.
The pattern: one customer, one key
Router One gives one account a managed upstream to 30+ supported models through a single wallet, and an account can hold many API keys. Each key has its own name, an optional expiry date and an optional spend cap that you set in Dashboard → API Keys:
- maxSpend — A key's spend cap (maxSpend) limits what that key can charge to your wallet: once its cumulative wallet charges reach the cap, its wallet-billed requests return HTTP 402. Requests covered by your plan's quota draw from the account's shared plan quota and do not count toward any key's cap.
- Expiry — an optional date after which the key stops working. Expired keys you have not deleted still count toward the account's active-key limit, so delete a key when its customer leaves.
Rate limits are not a key setting. Every key and every account runs under platform default request-per-minute and token-per-minute limits; if one customer's traffic needs more, email support@router.one with your account ID, the key and the expected peak requests and tokens per minute to have the key or account limits raised. Upstream capacity still applies.
That is enough to run a clean reseller loop:
- Create one key per customer, with a spend cap matching what they prepaid you.
- Use each key server-side, inside the service you run for that customer. Never publish a key or hand it to a customer to use on their own: keys stay under your control, and as the account holder you are responsible for all usage on them (see the terms of service).
- Review per-key usage — requests, tokens, spend — in Dashboard → Usage, and filter Dashboard → Logs by key to export one customer's requests to CSV.
- When a customer's key reaches its cap, its wallet-billed requests return HTTP 402, and your other customers' keys keep working.
- Re-bill, raise the cap, repeat.
One caveat if the account also has a Pro, Max or Ultra plan: the plan quota is shared by every key on the account, and requests the plan covers do not count toward any key's cap. One busy customer key can use up the plan quota for all of them, so think this through before adding a plan to an account that serves customers.
Your cost basis is the pay-as-you-go token line at each model's posted rate — the same per-1M-token prices published on the models page — plus checkout-visible FX/channel fees when you top up. Whatever you charge customers on top, for curation, integration, support, or uptime ownership, is your margin and lives in your invoice, not inside an opaque per-token markup. The reseller overview walks through the full setup.
Why spend caps are the load-bearing part
Reselling without per-key caps is a liability machine: one customer's runaway agent drains the shared balance and takes every other customer down with it. Caps turn that systemic risk into a per-customer inconvenience — the runaway key reaches its cap and its wallet-billed requests return HTTP 402 (see the error-code reference) — while everything else keeps serving. The same cap bounds what a leaked key can charge to your wallet; it does not stop plan-covered requests, so delete a leaked key rather than relying on its cap.
Keep the wallet itself funded, too: an empty wallet fails wallet-billed requests on every key of the account with HTTP 402. Poll GET /v1/balance from your server and top up before it runs dry (balance monitoring).
The second load-bearing part is attribution you can show. Per-request traces record model, tokens, cost, and latency per key, which means a customer disputing a bill can be answered with data rather than assertions. The cost tracking page describes exactly what the ledger records.
What this pattern does not give you
Be straight with yourself and your customers about the boundary. Key-level reselling on Router One does not include:
- White-label or custom branding — your customers' requests run against Router One's endpoints, not an API surface with your name on it.
- Sub-accounts or organizations — keys live in your single account; there is no customer login, seat management, or role system to hand out.
- Wholesale or volume pricing — you buy at the posted token line like every other account.
- Customer-facing billing — invoicing your customers, taxes, and payment collection are your job, in your tooling.
If your business needs those things, you need a different class of product (or a direct conversation about enterprise terms). Pretending key-level controls are a white-label platform is how resellers end up making promises their infrastructure can't keep.
One adjacent note: Router One also has a separate referral program (a default 5% commission on referred users' wallet top-ups, credited to your wallet balance for model usage — not withdrawable today). That's a lighter-weight option if what you actually want is to recommend infrastructure rather than operate it.
FAQ
How does reselling LLM API access with spend-capped keys work? On Router One you create one API key per customer, set its maxSpend cap to match what that customer prepaid you, and use the key server-side inside the service you run for them; the key stays with you, not with the customer. Per-key usage — requests, tokens, spend — shows in Dashboard → Usage, and the reseller overview walks through the full setup.
What happens when a customer's spend cap is reached? That key's wallet-billed requests return HTTP 402: it cannot charge your wallet past the cap, and your other customers' keys keep working. If the account has a plan, requests the plan covers draw from the shared plan quota and do not count toward the cap. You re-bill, raise the cap, and repeat; if a key leaks, delete it.
How many keys can one account hold? An account can hold many keys, so one key per customer or per customer group works. Expired keys that you have not deleted still count toward the account's active-key limit, so delete keys for customers who leave.
Can I raise the rate limit for one busy customer? Rate limits are platform defaults per key and per account, not a setting you change in the dashboard. Email support@router.one with your account ID, the key and the expected peak requests and tokens per minute to have the key or account limits raised; upstream capacity still applies.
Does Router One offer white-label branding or wholesale pricing to resellers? No. Key-level reselling does not include white-label or custom branding, sub-accounts, wholesale or volume pricing, or customer-facing billing — you buy at the posted token line like every other account, and your customers' requests run against Router One's endpoints. How to build your own white-label layer on top of Router One — your brand and billing, a managed upstream underneath — is covered in the white-label guide; how volume buying actually works without a wholesale price list is covered on the wholesale page.
How do I handle a customer who disputes their bill? With data: per-request traces record model, tokens, cost, and latency per key, so a disputed bill can be answered with data rather than assertions. The cost tracking page describes exactly what the ledger records.
Is there a lighter option than operating keys for customers? Yes — Router One has a separate referral program (a default 5% commission on referred users' wallet top-ups, credited to your wallet balance for model usage — not withdrawable today). It is the lighter-weight option if what you actually want is to recommend infrastructure rather than operate it.
Who this fits
The key-per-customer pattern fits operators who own the customer relationship and the integration work: agencies running AI features inside client deliverables, consultants managing a handful of accounts, small tools with metered AI inside. It deliberately doesn't fit anyone promising customers "their own platform" — and that's the point. The capability set is small, but every piece of it is real: managed upstream, per-key caps on wallet charges, per-request usage data, and a posted rate you can build a margin on honestly.
Set up the first customer key at router.one, and see the reseller page for the complete capability list — including the explicit not-provided list. The two companion pieces are per-key cost attribution and production fallback behavior.