> ## 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. # Retire the venue > Retires the venue for good. Use it when the venue is finished, such as a sandbox venue you built to test with. Send `confirmName` as the venue's current `name`, exactly as reading the venue returns it, so the venue retired is the one you meant; any other name is refused and changes nothing. Retiring revokes every Venue key the venue holds, the one you call with among them, revokes its provider connections and retires its routes. Every account it holds is halted, so it takes no new exposure, and leaves its trader's account list and Connect, with its history kept. The venue leaves your organization's list of venues and Connect's tiles. Read by its id, it answers with `state` `retired`, and every other write to it is refused with `409` `venue_retired`. There's no way back. In production it's refused until every account the venue holds is flat and settled and holds none of its trader's money. In the sandbox it retires whatever its test accounts hold, and a position one of them holds stays open on the halted account. The response is the retired venue and what the retirement ended; a retry with the same `Idempotency-Key` and body answers the same, even with the Venue key the retirement revoked. Required scope: `venue:configure`. Preview: served on the sandbox to every venue, and production availability is arranged when a venue qualifies. Trading API keys and pre-registration keys do not authorize these routes. ## OpenAPI ````yaml /api/openapi.json post /api/venues/{venueId}/retire openapi: 3.1.0 info: title: trdrs Engine API version: 1.1.0 description: >- ## API Reference Every route the trdrs engine serves, with what to send and what comes back. It covers market data and news, trading and account state for a trader's own software, the Connect API a Connect app's backend calls and the Connect dashboard's routes, Connect pre-registration, the statements that carry a Connect account between environments, the venue routes a prop firm or brokerage runs its accounts through, and a trader's own challenges. Start with the Quickstart for your first call. The API standards hold the rules every route shares: keys, errors, rate limits, idempotency, paging and streaming. servers: - url: https://app.trdrs.co description: Production - url: / description: This engine security: [] tags: - name: Venue platform preview description: >- Run your venue: its providers, instruments, conditions, groups, routes, stages, venue rules, keys, accounts, usage, balance receipts and webhooks. These routes are in preview. They are served on the sandbox to every venue, and production access is arranged when a venue qualifies. Every route here under `/api/venues/` takes a Venue key. The back office reaches the same routes under `/api/back-office/` with a verified owner’s session, because the Venue key stays on your server, and both run the same checks. The team’s routes under `/api/organizations` serve the back office and the Connect dashboard alike, since one organization can run venues and Connect apps with one team. - name: Market data description: >- Search and look up symbols, read price history and quotes, check the server clock, and stream live bars. Crypto prices come from each provider’s public feed. Futures prices are licensed to each user and stream only from that trader’s own futures source: a login on their venue’s production Rithmic system, under their own market data subscription. A Rithmic Test login carries no market data. Futures reach the trader’s own signed-in session, and a venue’s or Connect app’s backend acting for its trader. A Trading API key reads crypto market data only. Without a source, a futures request answers 503 `feed_requires_connection` and the symbol search lists no futures. - name: News description: >- Market news and the economic calendar, from licensed and open sources, tagged with futures roots as they arrive. The content is the same for everyone, and these routes admit the same callers as market data: a licensed origin, a session or a Trading API key. Page headlines by publish time, filter them by instrument root, and stream them live over server-sent events. Thumbnails come through the image route. - name: Trading description: >- Place, change and cancel orders, protect a position with a bracket and change or withdraw it, and close or flatten positions. Every call that places an order takes a `clientOrderId` as its idempotency key. - name: Account description: >- Read an account a trader can trade: its balance, positions, working orders, fills, profit and loss history, and the live account stream. You don’t create accounts here. A trader connects their own account at a provider, or opens their own Demo on the paper book, in the trdrs app. A venue issues accounts on the paper book with Issue an account into a group, and a venue pre-registers accounts at a provider through Connect with Pre-register a trader’s account. - name: Connect description: >- Connect is the account picker a trader opens: in the trdrs app, where it lists the built-in providers and every listed venue, and in hosted Connect on a Connect app’s website, where it lists the tiles the app chose. The pre-registration routes let a venue fill Connect in the trdrs app ahead of time, for a trader who signs in to trdrs. You tell trdrs that a trader has an account at a built-in provider: their sign-in email, and optionally the account number and login name. When that trader signs in, Connect shows the account ready to link, and they sign in to the provider themselves, once. The trader types their own password, and access starts when their own login succeeds. You can list who you pre-registered and who has linked, and cancel a pre-registration that hasn’t been used. A pre-registration expires after 30 days, and sending it again refreshes it. These routes take the pre-registration key. [Register an account](/guides/register-an-account) walks through the whole flow. - name: Connect apps preview description: >- Run a Connect app: your own trading interface, whose traders connect their accounts in hosted Connect on your website and trade them on your screens. The Connect API is what your backend calls with your app’s API key: Create a Connect link, read and close it, and the account, market and trading routes with your trader named in `x-trdrs-trader`. Hosted Connect calls its own routes with the frame session a Connect link opens. The Connect dashboard calls the rest with your Connect sign-in session: your apps, each app’s name and logo, API keys, websites, tiles, white-label paper and Demos, traders and active traders, invoices, conformance runs and its Connect pass. These routes are in preview, served on the sandbox, where they are free. An app’s production opens when production records the app’s Connect pass, which the sandbox signs once the app passes its Connect conformance run. - name: Connect accounts description: >- A Connect client's team signs in to the Connect dashboard with a Connect account of its own, never a trader's, and one login reaches both environments. Production answers a short statement for the signed-in account, naming its verified email and the Connect apps it owns, and sandbox exchanges it for a sandbox session and the counterpart app of each: the sandbox app that stands for the production one. The environments share no credential: production signs the statement with its own key, and sandbox checks it with production's public key alone. These routes take the Connect dashboard's own session, from the dashboard's origin; a trader's session and every key are refused, and a Connect account's session reaches no trading, account, market or AI route. - name: Challenges description: >- List evaluation programs, enroll in one, and read a trader’s own enrollments and their history. **Preview: outside the additive-only promise**, so these shapes can change; see Versioning and stability. **They take a signed-in session, not a key**, and exist only on an engine that runs with `CHALLENGES_ENABLED`. Anywhere else every one answers `404`. paths: /api/venues/{venueId}/retire: post: tags: - Venue platform preview summary: Retire the venue description: >- Retires the venue for good. Use it when the venue is finished, such as a sandbox venue you built to test with. Send `confirmName` as the venue's current `name`, exactly as reading the venue returns it, so the venue retired is the one you meant; any other name is refused and changes nothing. Retiring revokes every Venue key the venue holds, the one you call with among them, revokes its provider connections and retires its routes. Every account it holds is halted, so it takes no new exposure, and leaves its trader's account list and Connect, with its history kept. The venue leaves your organization's list of venues and Connect's tiles. Read by its id, it answers with `state` `retired`, and every other write to it is refused with `409` `venue_retired`. There's no way back. In production it's refused until every account the venue holds is flat and settled and holds none of its trader's money. In the sandbox it retires whatever its test accounts hold, and a position one of them holds stays open on the halted account. The response is the retired venue and what the retirement ended; a retry with the same `Idempotency-Key` and body answers the same, even with the Venue key the retirement revoked. Required scope: `venue:configure`. Preview: served on the sandbox to every venue, and production availability is arranged when a venue qualifies. Trading API keys and pre-registration keys do not authorize these routes. parameters: - name: venueId in: path required: true schema: type: string format: uuid - name: Idempotency-Key in: header required: true schema: type: string minLength: 1 maxLength: 128 description: >- A key you choose, 1 to 128 characters, that identifies this write. Send the same key when you retry it, so the write is never applied twice. requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/VenueRetireRequest' responses: '200': description: >- Success. The response is sent with `Cache-Control: no-store`, so don't cache it. content: application/json: schema: $ref: '#/components/schemas/VenueRetireResponse' '400': description: >- The request is malformed: invalid JSON or input, a bad cursor, or a missing `Idempotency-Key` or `If-Match` header. When one value is refused, `field` names it where the check can say which. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '401': description: >- The Venue key is missing, malformed, revoked or expired. A key the retirement revoked answers only a retry of that retirement. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '403': description: >- The key lacks `venue:configure`, or the owner who issued it is no longer an owner. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: >- The venue, account or resource doesn't exist in this environment, or isn't yours to see. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '409': description: >- `confirm_name_mismatch`: `confirmName` isn't the venue's current name. `not_quiescent`: in production, an account the venue holds still holds something, and `blockers` names each account with its `reason`: `position_open`, `working_order`, `pending_command` (a command of the account has no verdict yet), `account_state_unknown` (an account at a provider whose state isn't proven), `not_settled` (a funding or financing charge the account owes, or one waiting on its record or rate) or `balance_held` (a brokerage account whose balance isn't zero). Settle each, then send the request again. `venue_retired`: the venue is retired already, by another request. `demo_venue_managed`: the venue is trdrs's Personal Demo venue, which never retires. `idempotency_conflict`: the `Idempotency-Key` retired this venue with another body. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '413': description: The body is larger than this route accepts. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '415': description: 'Send the body as JSON, with `Content-Type: application/json`.' content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '503': description: >- trdrs can't complete the request right now, because a part of the venue platform or its credential store is unavailable. Don't assume a write happened: retry it with the same `Idempotency-Key`. `engine_draining` with a `Retry-After` header: the engine you reached is restarting for a release and did nothing. Wait for `Retry-After`, then send the same request again, with the same `clientOrderId` or `Idempotency-Key` where the route takes one: another engine takes it. A write refused before any route takes it says `server draining` as its `error`. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' headers: Retry-After: $ref: '#/components/headers/RetryAfter' security: - venueKey: [] x-codeSamples: - lang: javascript label: TypeScript source: >- const res = await fetch('https://app.trdrs.co/api/venues/{venueId}/retire', { method: 'POST', headers: { 'content-type': 'application/json', Authorization: `Bearer ${process.env.TRDRS_VENUE_KEY}`, "Idempotency-Key": "example-request-1", }, body: JSON.stringify({ "confirmName": "Example venue" }), }) const data = await res.json() - lang: shell label: cURL source: |- curl -X POST 'https://app.trdrs.co/api/venues/{venueId}/retire' \ -H "Authorization: Bearer $TRDRS_VENUE_KEY" \ -H 'Idempotency-Key: example-request-1' \ -H 'content-type: application/json' \ -d '{"confirmName":"Example venue"}' components: schemas: VenueRetireRequest: type: object additionalProperties: false properties: confirmName: type: string maxLength: 200 description: >- The venue's current `name`, exactly, as typed confirmation that this is the venue to retire. required: - confirmName example: confirmName: Example venue VenueRetireResponse: type: object additionalProperties: false properties: venue: $ref: '#/components/schemas/VenueRecord' retirement: type: object additionalProperties: false properties: retiredAt: type: string format: date-time accounts: type: integer description: >- The accounts the venue held, each now halted and gone from its trader's lists. keys: type: integer description: The Venue keys it revoked. connections: type: integer description: The provider connections it revoked. routes: type: integer description: The routes it retired. required: - retiredAt - accounts - keys - connections - routes description: What the retirement ended, and when. required: - venue - retirement example: venue: id: 00000000-0000-0000-0000-000000000001 organizationId: 00000000-0000-0000-0000-000000000001 name: Example venue environment: sandbox state: retired version: 3 createdAt: '2026-09-14T12:00:00.000Z' rules: applies: orders: true fills: true stages: true appliesAtProvider: orders: false fills: false stages: false company: null retirement: retiredAt: '2026-10-26T12:00:00.000Z' accounts: 12 keys: 2 connections: 1 routes: 1 ErrorResponse: type: object description: >- The body of every error response. It always carries `error`, an English sentence you can show. A refused trading request also carries `code`, one of the refusal codes, and `params`, the details of that refusal. Translate by `code` and `params`, and show a generic message for a code you don't recognize. Other errors may carry a `code` of their own. properties: error: type: string description: What went wrong, as an English sentence. code: type: string description: >- A stable machine code. On a refused trading request, it is one of the refusal codes. params: type: object description: >- The details of the refusal named by `code`, on a refused trading request. required: - error example: error: invalid_instrument VenueRecord: type: object additionalProperties: false properties: id: type: string format: uuid organizationId: type: string format: uuid name: type: string environment: type: string enum: - sandbox - production state: type: string enum: - draft - active - halted - retired description: >- `retired` once an owner retired the venue, for good: it's gone from your lists and Connect, and every write to it is refused. version: type: integer createdAt: type: string format: date-time rules: type: object additionalProperties: false properties: applies: type: object additionalProperties: false properties: orders: type: boolean fills: type: boolean stages: type: boolean required: - orders - fills - stages appliesAtProvider: type: object additionalProperties: false properties: orders: type: boolean fills: type: boolean stages: type: boolean required: - orders - fills - stages required: - applies - appliesAtProvider description: >- Venue rules: your own order limits, stages and analytics on the accounts the venue holds. Configured terms apply without an activation switch. `applies` says what trdrs applies today to an account issued on the paper book: `orders` (the halt, instrument list, and size and notional limits, checked before an order is accepted), `fills` (markup, collar and commission at the fill) and `stages` (eligibility read from the account's own fills). `appliesAtProvider` says the same for an account held at a provider, and all three are false there: the provider's orders and fills don't pass through these rules, and stage performance needs a verified start of the cycle that a first snapshot can't give. A false entry means the setting is saved but not applied to trading yet. company: oneOf: - $ref: '#/components/schemas/CompanyRecord' - type: 'null' description: >- The venue's company, which holds its brand, its listing state and its slug. Null only for an early venue no company could be matched to. required: - id - organizationId - name - environment - state - version - createdAt - rules - company CompanyRecord: type: object additionalProperties: false properties: id: type: string format: uuid name: type: string blurb: type: - string - 'null' logoUrl: type: - string - 'null' logoBleed: type: boolean referralUrl: type: - string - 'null' sortOrder: type: integer builtInProvider: type: - string - 'null' enum: - rithmic - tastytrade - hyperliquid - binance - bybit - paper - null description: >- On a built-in provider's company, its provider id; null on a venue's or a public provider's. listingState: type: string enum: - draft - conformance_passed - submitted - in_review - changes_requested - approved - listed - suspended slug: type: string pattern: ^[a-z0-9]+(-[a-z0-9]+)*$ maxLength: 40 description: >- The company's name in the API, the same in sandbox and production: a built-in provider's provider id, or one made from the company's name when it was created. It can change until the company is approved, and is fixed from then on. enabled: type: boolean createdAt: type: string format: date-time updatedAt: type: string format: date-time required: - id - name - blurb - logoUrl - logoBleed - referralUrl - sortOrder - builtInProvider - listingState - slug - enabled - createdAt - updatedAt description: >- A company on trdrs: one venue or one provider, with its brand, its listing state and its slug. Each of the six built-in providers is a company with `builtInProvider` set, and what it is and does (its kind, the asset classes its route takes, whether a venue can plug it in and how it is signed into) is its row in the provider table, which `GET /api/connect/providers` lists. headers: RetryAfter: description: >- How many seconds to wait before sending the same request again. A `503` carries it only when the engine did nothing, so the request may be sent again as it is. schema: type: integer minimum: 1 securitySchemes: venueKey: type: http scheme: bearer description: >- The Venue key (`trdrs_vk_sandbox_…` or `trdrs_vk_production_…`), in preview. It belongs to one venue in one environment and carries the scopes it was created with. The venue's verified owner creates it while signed in. It works on the `/api/venues/{venueId}` routes and, with `trader:read` or `trader:trade`, on the account, market and trading routes, reading the venue's own traders' accounts and routing their orders, each request naming its trader in `x-trdrs-trader`. A `trdrs_sk_…` key can't be used in its place. It reaches its venue's routes and its venue's own traders, and the owner manages keys from a signed-in session. Keep it on your server. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.