Security & privacy

Keep API keys on the server

Treat a Router API key as a secret. Store it in a server-side secret manager or environment variable. Never include it in browser JavaScript, mobile application bundles, public repositories, support messages, or screenshots.

Give each application its own named key. This makes usage easier to attribute and lets you revoke one integration without interrupting others.

Rotate an exposed key

1. Create a replacement in API keys.
2. Update the application secret and verify a request with the new key.
3. Revoke the exposed key.
4. Review Usage for unexpected requests.

Keys expire after 90 days, and an account can have at most 10 active keys. Revocation blocks new requests; an already-running request may finish.

Understand where prompts run

Router sends request content to a participating provider computer running the selected model. That computer can access the prompt and generated content while performing inference. Choosing a public offer identifies the intended computer/model offer, but its profile, avatar, and website are self-described. Publication does not establish verified identity, reputation, confidential execution, or independently verified token counts. Use non-sensitive prompts; participation does not establish that a provider is trusted.

Minimize application data

Send only the conversation turns needed for the next answer. Remove internal metadata and secrets before building messages. Keep your own logs free of bearer tokens and full request content unless you have a deliberate retention and access policy.

Router usage records

API usage history stores operational metadata such as request ID, endpoint, timing, status, error code, and provider-reported token counts. It excludes prompts, answers, and key secrets.

Router's execution storage is separate from usage history. Accepted assignments, including message content, are stored in PostgreSQL to coordinate requests; runtime terminal evidence can also contain output, and bounded output is transported through Redis. Finished Redis output expires after 60 seconds. Finished PostgreSQL runtime records become eligible for bounded cleanup after the request deadline plus 20 minutes, once pending effects are reconciled. Backlogs, unresolved work or outages can extend retention; these application cleanup rules do not establish deletion times for backups.

Completed paid answers are available to the account owner through credit receipts for 24 hours. Router then clears the stored answer during bounded recovery; a backlog or outage may delay that cleanup. Financial receipt metadata remains.

Review authentication for the key lifecycle and message design for keeping prompts concise.