Venue keys

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.

​

Mint one in the back office

A Venue key is minted from the back office, 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. 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.

​

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. The Partner key (trdrs_sk_…) is what Connect pre-registration and the Legacy Partner API take; a venue that only lists a built-in provider and pre-registers traders still holds one for that.