> ## 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. # Venue keys > The one key a venue's backend uses, and the signed-in session the back office uses for the same calls: what each may hold, and which calls exist only for a person. A venue is configured through one set of routes reached two ways. Your own backend calls with a Venue key. The back office, and any browser, calls with the signed-in session. Which credential you hold decides what may keep the secret, and nothing else: the same validation runs, the same compare-and-swap guards the same revisions, and the same refusal comes back word for word. | | Venue key | Session | | ------------- | ---------------------------------- | ------------------------------------------------------- | | Path | `/api/partner/venues/…` | `/api/operator/venues/…` | | Credential | `Authorization: Bearer trdrs_vk_…` | the signed-in cookie | | Also required | the key's scopes | a verified owner, and a trusted `Origin` on every write | | Held by | your own backend | a browser, and only a browser | ## Mint one in the back office A Venue key is minted from the [back office](https://sandbox.trdrs.co/developer), on the Developers tab, for one venue, in one environment, with the scopes you tick. Sandbox keys begin `trdrs_vk_sandbox_…` and production keys `trdrs_vk_production_…`; neither works in the other environment. The plaintext is shown once. Issuing and revoking a key is session-only: no key may mint another key. | Scope | What it opens | | ------------------------------------------------ | ------------------------------------------------------------------------------------ | | `venue:read` | reading the venue, its instruments, conditions, routes, providers and stage policies | | `venue:configure` | instruments, conditions, groups and per-account safety limits | | `routing:write` | routes, and pointing a group at one | | `provider:manage`, `connection:manage` | providers and the connections to them | | `account:issue`, `account:read`, `account:reset` | issuing, listing and resetting the venue's accounts | | `balance:write` | credits, debits and adjustments | | `risk:halt` | halting and resuming an account | | `stage:advance` | stage policies, eligibility and advancement | | `grant:manage` | invitations on a bound account | A key missing the scope a route names is refused before anything is read. Every key-authorized call rechecks venue, environment, scope, expiry, revocation and the issuer's current ownership in its own transaction. ## A browser never holds a Venue key A Venue key authenticates a venue's own server. Putting one in a browser hands every person who opens the developer tools a credential that configures your venue, so the session path exists precisely so that never has to happen. The back office uses it, and there is no build of the back office that accepts a key. The two are also judged differently, because the requests differ. A key arrives with an `Authorization` header and no `Origin`; a browser arrives with an `Origin` and no header. A write from a browser with no trusted `Origin` is refused as `origin_not_allowed`, and a bearer header is never accepted as an exemption from that check. ## Every configuration call exists on both Instruments, conditions, groups, routes, stages, providers, the venue's accounts (issue, list, balance, reset, halt, resume, analytics, the five risk controls) and the firm's own services (usage, the receipt of a balance operation, webhooks) are reached at the same suffix under either prefix. That last group is what makes one Venue key enough for a venue's backend: nothing it needs is left on the Legacy Partner key. `POST /api/partner/venues/{venueId}/routes` and `POST /api/operator/venues/{venueId}/routes` create the same route, take the same body and the same `Idempotency-Key`, and refuse the same things. The reference lists the Venue key form of each of these. Swap the prefix and drop the bearer header to read it as the session call. ## Six calls exist only on the session These are the calls made *before* a venue exists, or about the person rather than the venue. A key names a venue, so it could not express them even if a browser were allowed to carry one. | Call | What it is | | ---------------------------------------------- | ---------------------------------------------- | | `GET`/`POST /api/operator/organizations` | The organization that owns venues | | `GET /api/operator/organizations/{id}/venues` | Your venues, so nothing has to paste a UUID | | `GET /api/operator/organizations/{id}/members` | Who may operate them | | `POST /api/operator/venues` | Create a venue | | `GET /api/operator/venues/{venueId}` | Read one | | `POST /api/operator/venues/{venueId}/firm` | [Adopt your firm](/guides/run-a-venue) into it | ## Which one to use Use the session when a person is deciding: setting up a venue, changing a collar, publishing a pricing plan. Use the key when your own software is deciding, on a schedule or in response to something your system saw. Neither is a fallback for the other. A key that has lost its scope is not fixed by signing in, and a session that is not an owner is not fixed by minting a key. ## The other keys A Venue key cannot place a trader's orders or read market data; that is the [Trading API key](/partner-platform/overview/keys). The Partner key (`trdrs_sk_…`) is what Connect pre-registration and the [Legacy Partner API](/guides/run-firm-accounts) take; a venue that only lists a built-in provider and pre-registers traders still holds one for that.