Connected apps

Connected Apps lets an external application use AnonRouter without asking for your API key or learning your AnonRouter profile. The app receives a private, app-specific identifier and permission to run inference in a dedicated workspace.

Developers can use the same feature, called AnonRouter Connect, to add Sign in with AnonRouter to a confidential server-side application. Connect uses the OAuth 2.1 authorization-code flow, OpenID Connect, and PKCE.

Open your connections and developer apps at Dashboard → Account → Connected apps.

What an authorized app receives

Every grant has two fixed scopes: openid and inference.

The identifier in the OpenID Connect sub claim is pairwise: unrelated app security domains receive different identifiers for the same AnonRouter account. This makes the identifier useful as the app's private account key without making it a global AnonRouter identity.

The dedicated workspace separates the app's usage from your other workspaces. AnonRouter uses a hidden attribution credential internally, but that credential is never returned to the app.

Connect to an external app

You normally start on the external application's website by selecting Sign in with AnonRouter.

1. The app redirects you to AnonRouter. If needed, sign in on the AnonRouter domain. Do not enter your AnonRouter password or recovery phrase directly into the external app.
2. Check the app name. AnonRouter explains that the app will receive a private, app-specific identity rather than your profile.
3. Review the app name, callback hostname, requested permissions, and any linked Privacy Policy or Terms of Service.
4. Optionally enable a Lifetime spending cap. The cap includes successful usage and the cost reserved for requests that are still running.
5. Optionally enable Expires after and choose how many days the grant should remain active.
6. Select Authorize to continue or Cancel to deny the request. AnonRouter returns the browser only to the app's exact registered callback address.

Authorizing an app creates its dedicated workspace. A later authorization for the same app reuses that workspace while creating a new explicit grant.

Review or disconnect an app

The Connected apps table shows each authorization's app, dedicated workspace, scopes, successful and reserved spend, approved cap, last use, and status. A grant can be Active, Expired, or Disconnected.

To end access:

1. Open Connected apps.
2. Find the active grant.
3. Select Disconnect and confirm.

Disconnecting invalidates the grant's access and refresh tokens immediately. The dedicated workspace and its usage history remain on your account for attribution and auditing. You can reconnect later by starting a new authorization from the app.

Signing out of AnonRouter only ends the browser session; it does not disconnect an app. Password recovery, account disablement, app deletion, secret rotation, and security-sensitive app configuration changes can also revoke grants.

Register your own app

AnonRouter Connect is intended for confidential applications with a server-side component that can protect a client secret. A browser-only SPA, native app, or other public client must put the Connect exchange and token storage behind a trusted backend. Never embed a client secret in browser JavaScript, downloadable application code, or a mobile binary.

To register an app:

1. Open Connected apps and scroll to Your apps.
2. Select Create New App.
3. Enter the app name that users should see during authorization.
4. Enter one or more exact redirect URIs, one per line.
5. Optionally add a Privacy Policy URL and Terms of Service URL. AnonRouter shows these links during authorization and in the user's connection menu.
6. Select Create app.
7. Copy the client ID and client secret before closing the dialog. The secret is displayed once and cannot be retrieved later.

Store the client secret in a server-side secret manager or protected environment variable. Do not commit it, log it, place it in a URL, or send it to the browser.

Registration rules

• An account can have up to 10 enabled developer apps.
• App names are limited to 120 characters and cannot impersonate AnonRouter.
• An app can register between 1 and 20 exact redirect URIs.
• Redirect URIs cannot contain wildcards, embedded credentials, or fragments. Paths, ports, query strings, and trailing slashes are significant.
• Every redirect URI for one app must use the same hostname. AnonRouter derives the pairwise-identity security domain from that hostname.
• Production redirect and policy URLs require HTTPS and cannot target localhost. A local AnonRouter development environment permits HTTP only on localhost, 127.0.0.1, or [::1].

Rotate a secret

Use Rotate secret when a secret is lost, exposed, or due for replacement. The old secret stops working immediately, all current grants for the app are revoked, and users must authorize the app again. The replacement secret is also displayed once.

Delete an app

Deleting an app disables its credentials and disconnects everyone who authorized it. This cannot be undone from the dashboard. Register a new app and ask users to authorize it if service needs to resume.

Integrate Sign in with AnonRouter

Use a maintained OpenID Connect client library instead of constructing the protocol by hand.

Use the discovery document for the authorization, token, UserInfo, revocation, and JWKS endpoints. Do not hard-code those endpoint paths.

Connect is a control-plane feature end to end. The issuer, the discovery document, and the two endpoints a Connect access token can reach — the model list and the ticket mint — are all served from control.anonrouter.ai. Content goes to api.anonrouter.ai and nowhere else, so an integration needs both base URLs. See Run delegated inference.

Authorization flow

1. On your server, generate a PKCE verifier and S256 challenge, a random state, and an OpenID Connect nonce.
2. Redirect the browser to the discovered authorization endpoint with your client ID, one exact registered redirect URI, response_type=code, scopes openid inference, the PKCE challenge, state, and nonce.
3. At the callback, reject any state mismatch. Exchange the short-lived code from your server using client_secret_basic, the original redirect URI, and the original PKCE verifier.
4. Verify the ID-token signature against the discovered JWKS, then validate its issuer, audience, expiry, and nonce. Use sub only as this app's private account key.
5. Store access and refresh tokens only on your server. Give the browser an opaque application session cookie instead of the Connect tokens.
6. Replace the stored refresh token every time you refresh. Connect refresh tokens rotate; reusing a consumed token revokes the complete token family.
7. Use the discovered revocation endpoint when the user disconnects inside your app, then clear the app's local session and tokens.

Access tokens are intentionally short-lived. Refresh tokens let your server continue the approved grant without asking the user to sign in every few minutes; they do not bypass expiry, spending limits, account funding, app status, or user revocation.

Run delegated inference

Send the Connect access token as Authorization: Bearer <token> to the control base URL. It can list models and request a content-free, single-use inference ticket. It cannot call protected account APIs.

For example, request a ticket for a chat completion:

curl https://control.anonrouter.ai/v1/inference/tickets \
  -H "Authorization: Bearer $ANONROUTER_CONNECT_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "/auto",
    "operation": "chat",
    "max_tokens": 512
  }'

Then send the returned ticket—without the Connect access token—to the content request in x-anonrouter-ticket. The ticket is short-lived, single-use, and bound to the request constraints:

curl https://api.anonrouter.ai/v1/chat/completions \
  -H "x-anonrouter-ticket: $ANONROUTER_TICKET" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "/auto",
    "max_tokens": 512,
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Do not send the Connect access token with the content request. This keeps the stable app authorization on the control plane while the content relay receives only the opaque single-use ticket. The hosts enforce the split rather than relying on you to honor it: control.anonrouter.ai does not serve /v1/chat/completions, and api.anonrouter.ai does not serve /v1/inference/tickets. Sending either request to the other host returns 404. See How privacy works for the full request boundary.

Troubleshooting

The callback is rejected

Compare the callback with the registered URI byte for byte, including scheme, hostname, port, path, query string, and trailing slash. Production callbacks must use HTTPS. If a callback destination changes, users must authorize the new configuration.

Inference is denied after authorization

Check the user's account balance, grant status, optional expiry, spending cap, and the app's status. Reserved in-flight requests count toward the cap. A user must start a new authorization to approve a different cap or expiry.

The client secret is lost

Secrets cannot be recovered. Rotate the secret under Your apps, store the new value immediately, and have users reconnect.

Users were disconnected after an app change

Secret rotation, app deletion, and security-sensitive callback changes revoke existing grants by design. This prevents old consent from carrying over to new credentials or redirect destinations.

The authorization interaction expired

Authorization interactions and codes are short-lived and single-use. Return to the external app and select Sign in with AnonRouter again instead of reloading or revisiting the old consent URL.