> ## 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.

# Two doors into a venue

> The same venue operations are reached two ways: a venue key from your backend, or a signed-in session from a browser.

A venue is configured through one set of services behind two front doors. Which door you are at
decides what may hold 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                           |

## 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 operator door exists precisely so
that never has to happen. The console at `/developer` uses it, and there is no build of that console
that accepts a key.

The two doors 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 and the firm's accounts (issue, list,
balance, reset, halt, resume, analytics) are reached at the same suffix under either prefix. `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 partner form of each of these. Swap the prefix and drop the bearer header to
read it as the operator call.

## Six calls exist only on the session door

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 |

Issuing and revoking a venue key is session-only for the same reason in reverse: no key may mint
another key.

## Which one to use

Use the session door 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.