> ## 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. # List existing accounts with original rules > Preview: served on the sandbox to every venue; production availability is arranged when a venue qualifies. Trading API keys and Partner keys do not authorize these routes. Requires a verified authorized operator session; writes require a trusted origin. account:read. Lists accounts issued by the linked issuer that have no venue binding. Includes closed accounts. This read creates no bindings and changes no trading rules. Bound accounts are excluded even if held by another venue. Balance and currency are null when no paper record exists. Pagination is not a cross-page snapshot; refresh after migration. ## OpenAPI ````yaml /partner-platform/openapi.json get /api/operator/venues/{venueId}/existing-accounts openapi: 3.1.0 info: title: trdrs Engine API version: 1.1.0 description: >- ## API Reference This is the served OpenAPI contract for the trdrs engine: market data, trading and account routes for your firm's traders, trdrs Connect account-registration handoff, and preview challenge routes. See Quick Start for the first integration path: key setup, market config, chart data, Connect account registrations, idempotency, stream reconnects, and conformance. See Overview and API Standards for the cross-cutting contract rules. servers: - url: https://app.trdrs.co description: Production - url: / description: This engine security: [] tags: - name: Venue platform preview description: >- The venue routes, in preview: a venue’s providers, instruments, conditions, groups, routes, stages, level 2, keys, accounts, usage, balance receipts and webhooks. Served on the sandbox to every venue; production availability is arranged when a venue qualifies. Every route documented here under /api/partner/ takes a Venue key and is also served under /api/operator/ to a verified owner session, by the same router with a different credential: a browser never holds a Venue key, so the back office reaches the identical checks that way. Additive-only from here; the Legacy Partner API routes remain unchanged. - name: Market data description: >- Symbol search and resolution, OHLCV history, quote snapshots, the server clock, and the live bar stream. Crypto rides each provider’s public feed; futures stream from the caller’s own connected Rithmic account. With none connected, futures requests answer 503 `feed_requires_connection`. - name: News description: >- Aggregated market news and the economic calendar, from licensed/open sources, keyword-tagged with futures roots at ingest. Platform-wide content (nothing per-user), admitted exactly like Market data: a licensed origin, a session, or a Trading API key. Headlines page by published time, scope by instrument root, and stream live over SSE; thumbnails serve through the image proxy. - name: Trading description: >- The money routes: entries, exits, replaces, cancels, and position/account flattening. Every order-placing call uses `clientOrderId` as its idempotency key. - name: Account description: >- Reading a connected account. You do not create trading accounts here: a trader connects their own account at a provider (or opens their own Demo on the paper book) in the app, and a venue issues accounts on the paper book (Venue platform → Issue an account into a group; the Legacy Partner API’s Create evaluation accounts does the same) or pre-registers accounts at a provider through Connect (Pre-register a trader’s account). Account state and the durable ledgers: balances, positions, working orders, fills, P&L history, and the live account stream. - name: Connect description: >- Connect is the account picker a trader opens, in our app or embedded on a firm’s site: the built-in providers, plus every listed venue. These three routes are how a firm PRE-FILLS it. You tell us 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. Nothing here sends a password or grants access before the trader’s own login succeeds. You can list who you pre-registered and who has linked, and cancel a pre-registration that has not been used. Pre-registrations expire after 30 days; repeating one refreshes it. These routes take the Partner key and are Connect’s own; they are not part of the Legacy Partner API. The end-to-end flow is **[Quick Start](/docs/guides/quick-start)**. - name: Firm accounts (legacy) description: >- Legacy Partner API. Every route in this group has a venue twin under `/api/partner/venues/{venueId}/accounts…`, reached with a Venue key and a named scope, and new integrations use those; this group stays for firms that predate venues, and the same operation runs behind both. Evaluation accounts your firm issues on the paper book, through your Partner key. Connect pre-registers accounts that exist at a provider; these routes create and manage accounts on the paper book: the trader trades them on trdrs, and your firm owns the lifecycle. Every route is scoped to accounts your firm created through this API — an account the same trader opened themselves is invisible and untouchable here, by construction. Creation is batched with per-item results, and every write carries your own `referenceId`, so a crashed pipeline retries safely. Served when the deployment runs the prop engine; without it, every route in this group answers `404`. - name: Billing description: >- Legacy Partner API, per firm. What your firm is billed for in a month, computed from the execution ledger, and the accounts behind the number. The venue platform will carry per-venue usage; until it does these two routes answer the Partner key. - name: Webhooks description: >- Legacy Partner API, being replaced by venue-scoped events, which are not built yet; this is the one job a venue-only backend still needs a Partner key for, and nothing here is removed until they are. The outbound event bus: register an https endpoint and the platform pushes events to it instead of your back office polling us. Every delivery is signed (`trdrs-signature: t=,v1=` over `${t}.${rawBody}`) so you can prove it came from us and is fresh, and every delivery is durable — a failed attempt is retried with backoff for about nine hours and the whole log is readable, so an endpoint that was down is a delay rather than a lost event. Serves every venue alike: the account-registration (`registration.*`) events fire wherever Connect does, and the account events fire where the prop engine runs. - name: Challenges description: >- Legacy Partner API, being replaced by stage rules on the venue, which carry the firm’s half of this; the trader’s enroll flow has not moved yet. The prop evaluation routes: challenge programs and a trader’s own enrollments. **Preview: the one group on this page outside the additive-only guarantee** (the pre-contract v1 scaffold; the Phase-1 rebuild will change these shapes; see Stability). **Cookie-authenticated, not key-authenticated**, and served only when the engine runs with `CHALLENGES_ENABLED`; without that flag the bundle is absent and every route below returns `404`. The admin half of this is deliberately not documented here. It is platform administration, not licensed API. paths: /api/operator/venues/{venueId}/existing-accounts: get: tags: - Venue platform preview summary: List existing accounts with original rules description: >- Preview: served on the sandbox to every venue; production availability is arranged when a venue qualifies. Trading API keys and Partner keys do not authorize these routes. Requires a verified authorized operator session; writes require a trusted origin. account:read. Lists accounts issued by the linked issuer that have no venue binding. Includes closed accounts. This read creates no bindings and changes no trading rules. Bound accounts are excluded even if held by another venue. Balance and currency are null when no paper record exists. Pagination is not a cross-page snapshot; refresh after migration. parameters: - name: venueId in: path required: true schema: type: string format: uuid - name: after in: query required: false schema: type: string description: >- Pass the previous nextCursor unchanged, URL encoded. At most 100 rows per page. responses: '200': description: 'Scoped result. Cache-Control: no-store.' content: application/json: schema: $ref: '#/components/schemas/VenueExistingAccountListResponse' '400': description: Invalid input, cursor or required request/version header. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '401': description: Required credential missing or invalid. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '403': description: >- Verified identity, current owner membership or required scope missing. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: Disabled feature, unavailable resource or wrong venue/environment. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '409': description: Changed idempotent request or stale version. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '413': description: Request exceeds the bounded body size. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '415': description: JSON body required. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '503': description: Service or credential vault unavailable; no success is implied. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - sessionCookie: [] x-codeSamples: - lang: javascript label: TypeScript source: >- // First-party cookie auth: this runs in a signed-in trdrs session, not under an API key. const res = await fetch('https://app.trdrs.co/api/operator/venues/{venueId}/existing-accounts', { credentials: 'include', }) const data = await res.json() - lang: shell label: cURL source: >- curl 'https://app.trdrs.co/api/operator/venues/{venueId}/existing-accounts' \ -b "session=$TRDRS_SESSION" components: schemas: VenueExistingAccountListResponse: type: object additionalProperties: false properties: items: type: array items: type: object additionalProperties: false properties: accountId: type: string accountNumber: type: string brokerName: type: string email: type: string status: type: string enum: - active - closed issuedAt: type: string balance: type: - string - 'null' currency: type: - string - 'null' rules: const: original required: - accountId - accountNumber - brokerName - email - status - issuedAt - balance - currency - rules nextCursor: type: - string - 'null' required: - items - nextCursor example: items: - accountId: example-prior accountNumber: EVAL-PRIOR brokerName: paper email: trader@example.com status: active issuedAt: '2026-09-14T12:00:00.000Z' balance: '50000' currency: USD rules: original nextCursor: null ErrorResponse: type: object properties: error: type: string required: - error example: error: invalid_instrument securitySchemes: sessionCookie: type: apiKey in: cookie name: session description: >- The signed session cookie of a logged-in trdrs user. First-party/browser only; an API key cannot reach a route secured this way. ````