← TrustedRouter blog

Sign in with TrustedRouter

2026-08-03

TrustedRouter Sign in with TrustedRouter Your users bring their own AI, credits, and spending limit. APP Your app Ship an AI feature Suggest a spending cap USER Sign in New account starts at $0 No provider key to copy CONTROL Fund and cap $5 | $20 | $100 User chooses the maximum KEY Inference only Revocable PKCE protected One account. One capped key. Any supported model. The app gets a capped key. The user keeps billing control. TrustedRouter keeps no prompt or output logs. TrustedRouter.com

Your users should be able to pay for their own AI without finding, copying, and trusting you with a provider API key.

We shipped Sign in with TrustedRouter. An app sends its user to TrustedRouter. The user signs in, adds credits if needed, chooses exactly how much the app may spend, and approves one inference-only key. The app never receives a management key. It cannot change billing, inspect other keys, or take over the workspace.

A writing tool, coding agent, research app, or internal product can use the same flow. The app suggests a conservative limit. The user sees that number before approval, can change it, and can revoke the resulting key later. Model calls draw from the user's TrustedRouter balance, so the developer does not need to build a second inference billing system.

A person who creates a TrustedRouter account inside this flow starts at exactly $0 and receives only the inference key they explicitly approve. That closes an obvious credit-farming hole and makes the economic relationship honest from the first request.

The funding step lives inside consent. The user can add $5, $20, or $100, with $20 selected by default. Stripe processes the payment and saves the card to the user's TrustedRouter account. The card can be removed later from the Credits page. Existing users see their current balance and can skip funding when they already have enough.

The authorization itself uses PKCE. The app creates a verifier, sends only its SHA-256 challenge to TrustedRouter, and keeps the verifier for the code exchange. A stolen callback code is useless without it. The final key can carry a fixed, daily, weekly, or monthly maximum and an expiry. The user can revoke it at any time.

The obvious objection is that the writing app sees the writing. Of course it does. The user gave text to that application to improve it, and the application needs its own honest privacy policy. Once the app calls a model, TrustedRouter sends that request through the attested API gateway. TrustedRouter keeps no prompt or output logs, always. The delegated auth control plane handles identity, billing, and key metadata. It does not receive the model request body.

The official SDKs already support Sign in with TrustedRouter. The Python SDK ships create_oauth_authorization and exchange_oauth_key. The TypeScript SDK ships BrowserOAuthFlow. The Swift SDK ships TrustedRouterOAuth. They generate PKCE state, build the authorization URL, validate the callback, and exchange the code.

The complete flow is in the developer documentation, with SPA, backend, native, and loopback examples.

Add one button. Let the user choose the bill and the boundary.


Workspace access

Sign in

Choose a sign in method to access your TrustedRouter workspace.

By signing in you agree to the terms of service and privacy policy.