> ## Documentation Index > Fetch the complete documentation index at: https://docs.trdrs.co/llms.txt > Use this file to discover all available pages before exploring further. # Keys and authentication > Authenticate every request with a bearer key, and choose the key that reaches the routes you need. Every request to a key-scoped route carries a key in the `Authorization` header. This page says which key to use, what each one reaches, and how to keep it safe. Read it before you store your first key. ```http theme={null} Authorization: Bearer trdrs_vk_sandbox_... ``` A missing, malformed, expired or revoked key is refused with `401`. A valid key that doesn't carry what a route needs is refused with `403`, before anything is read. ## Choose your key There are three keys, and each reaches its own set of routes. None of them reaches another's. * Use a **Venue key** when your server runs a venue: its configuration, the accounts it issues, its usage and its webhooks. * Use a **Trading API key** for programmatic trading on the accounts of the person who owns the key: market data, orders and account state. * Use a **Partner key** only to pre-register traders for Connect, or if your firm still runs on the [Legacy Partner API](/guides/run-firm-accounts). Most firms need a Venue key and never need the others. [Core concepts](/concepts#where-each-key-fits) shows all three side by side. ## Venue key A Venue key (`trdrs_vk_…`) reaches the routes under `/api/partner/venues/{venueId}/…` for one venue in one environment. You choose its scopes when you create it, and each route names the scope it needs: | Scope | Opens | | - | - | | `venue:read` | Reading the venue and its configuration, stage eligibility, usage, and your webhooks and their deliveries | | `venue:configure` | Branding, instruments, conditions, groups, routes, risk policies, venue rules, and registering and testing webhooks | | `account:issue`, `account:read`, `account:reset` | Issuing, listing and resetting accounts. `account:read` also reads an account's analytics, its risk controls and the receipt of a balance operation | | `balance:write` | Credits, debits and adjustments | | `risk:halt` | Halting and resuming an account, and setting its risk controls | | `stage:advance` | Publishing and activating stage policies, and advancing an account | | `provider:manage`, `connection:manage` | Providers and the connections to them | | `connect:manage` | Opening Connect sessions from your site | | `grant:manage` | Invitations on an account | | `hedge:read`, `hedge:manage`, `hedge:execute` | Reading, configuring and running hedging | Give each key only the scopes its job needs. [Venue keys](/guides/venue-keys) lists the routes behind each scope. You create and revoke Venue keys in [profile API access](https://sandbox.trdrs.co/settings/api), as an owner of the venue. A key lasts as long as you choose when you create it, from one minute to 365 days. A sandbox key starts `trdrs_vk_sandbox_` and a production key `trdrs_vk_production_`, and neither works in the other environment. No key can create another key. The hosted back office calls the same venue operations with a signed-in session, at `/api/operator/venues/{venueId}/…`. Those session routes are in the OpenAPI document but not in this reference, because a key can't call them. Your backend uses the Venue key routes. ## Trading API key A Trading API key (`trdrs_sk_…`) reaches `/api/market/`, `/api/instruments`, `/api/news`, `/api/calendar`, `/api/trading/`, `/api/account/` and `/api/risk`, for the accounts its owner holds. It's a credential for a server, not a login. Everything else a signed-in trader can do, such as journals, alerts, scripts and preferences, stays behind the session, and a Trading API key can't reach it. New routes are closed to keys until they're opened one at a time, so a leaked key exposes only what keys can do. In the OpenAPI document this key's security scheme is named `tenantKey`. ## Partner key A Partner key looks exactly like a Trading API key (`trdrs_sk_…`) but reaches only `/api/partner/` outside the venue routes. Connect pre-registration lives there, and so does the Legacy Partner API, whose every call now has a venue route that a Venue key reaches. A Partner key can't trade, read a trader's account or fetch market data, and a Trading API key is refused on `/api/partner/`. Nothing in the key string tells you which of the two you hold, so store them under different names. ## Sessions A person signed in to the trading app or the back office carries a session cookie. It runs their own trading, their key management and the back office. Your integration uses a key, never a browser's session. ## Browser access to market data A chart in your web app can read market data straight from trdrs, without your server passing every request along. Market data routes admit browser requests from origins you register with us. Two rules keep this safe: * Only market data routes admit a registered origin. Trading and account routes always need a key, sent from your server. * If a request carries an `Origin` header, that origin must be registered, even when a valid key is attached. A key excuses a missing `Origin`, never an unregistered one. ## Get your keys Sandbox keys are free and self-service. Sign in to [sandbox API access](https://sandbox.trdrs.co/settings/api) and create one; the [quickstart](/quickstart) takes you from there to your first request. Sandbox Trading API and Partner keys start `trdrs_sk_sandbox_` and expire after 30 days, and creating a Partner key creates an unlisted test firm. In production, a verified owner creates Venue keys in profile API access. Production Trading API and Partner keys come with your commercial agreement, one per scope per environment. Profile API access lists and revokes them; creating one there isn't available yet. ## Keep keys safe A key is shown once, when you create it. For Trading API and Partner keys we store only a SHA-256 hash, so nothing in our database can be turned back into a working key. A Venue key is also kept encrypted, so that retrying its creation returns the same key. * Put a new key straight into your secret manager. * Don't commit it, log it, or send it to a browser or a mobile app. If a key ever reaches one, treat it as public and revoke it. * Give each environment its own key, so you can revoke one without touching the other. * If a key may have leaked, revoke it in profile API access and create a new one. The old key stops working on its next request. For an older key managed outside self-service, contact trdrs. No key reaches platform administration. That needs an authorized trdrs staff session.