> ## 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 the markets an account trades > Returns every market the account can enter now, and whose markets they are, for a symbol search to show. The list is the same judgment every order meets first (`GET /api/trading/match`), so an order on a listed market isn't refused for its market. Each row carries its market key, which symbol search rows and symbol-info carry as `market`, so a symbol from any feed is matched to the market it names. Required key: Trading API key. A Connect app's backend can also send it with the app's API key, and a venue's backend with its Venue key, which carries `trader:read` or `trader:trade`, each naming one of its own traders in `x-trdrs-trader`: it then runs on that trader's own accounts. ## OpenAPI ````yaml /api/openapi.json get /api/account/markets 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. Changes to these routes are additive only from here on. - 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. 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. The whole flow is in the **[Quick Start](/docs/guides/quick-start)**. - 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. Once production opens to Connect apps, it serves the route that records an app’s Connect pass, which opens the app’s production. - 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: >- These routes list evaluation programs and a trader’s own enrollments. **Preview: the one group in this reference outside the additive-only guarantee.** Their shapes will change when challenges are rebuilt; see Stability. **They take a signed-in session, not a key**, and are served only where the engine runs with `CHALLENGES_ENABLED`. Without it, the routes don’t exist and every one answers `404`. The administration half isn’t documented here, because it is trdrs’s own tooling, not part of the API. paths: /api/account/markets: get: tags: - Account summary: List the markets an account trades description: >- Returns every market the account can enter now, and whose markets they are, for a symbol search to show. The list is the same judgment every order meets first (`GET /api/trading/match`), so an order on a listed market isn't refused for its market. Each row carries its market key, which symbol search rows and symbol-info carry as `market`, so a symbol from any feed is matched to the market it names. Required key: Trading API key. A Connect app's backend can also send it with the app's API key, and a venue's backend with its Venue key, which carries `trader:read` or `trader:trade`, each naming one of its own traders in `x-trdrs-trader`: it then runs on that trader's own accounts. parameters: - name: provider in: query schema: type: string description: >- The provider the account is at, such as `rithmic` or `paper`. Omit it to use your default provider. An unknown value is refused with 400, never replaced with another provider. - name: account in: query schema: type: string description: >- The account number at that provider. It must be one of your own accounts, or the call is refused with 400. responses: '200': description: >- The markets. They depend on the account: - An account at an exchange (Hyperliquid, Binance, Bybit) trades the exchange's own perpetuals. Another exchange's perpetual is that exchange's market, on its own contract terms, so it isn't listed. - An account at a futures provider (Rithmic, Tastytrade) trades the futures products trdrs holds a contract specification for, as continuous futures (`ES1!`) and as dated contracts. A Rithmic continuous future names the contract its position trades now, by the product's roll rule. Tastytrade names its own active month, which `GET /api/trading/match` answers, so its front continuous future lists with `contract` null. A Rithmic login at a venue's system lists the same markets under the login's brand, and Rithmic refuses at order time what the venue doesn't permit. - An account on the paper book (a Demo or an account a venue issued) and an account a venue granted at a provider trade what the venue's catalog lists for the account and it can enter now. A dated contract is listed until its last trade, and the continuous futures are the listed contracts of each product in roll order, each trading as its contract until the front one rolls. - The paper book prices futures only from the trader's own futures source, a login on their venue's production Rithmic system, so it lists futures only for a trader who has one. - A CFD is listed only while a provider serves its price, and its `exchange` names that provider. `scope` names whose markets they are: the venue that issued the account, the brand of a login at a venue's system (`Apex` on Rithmic), or else the provider. A Demo has none. When the account stream's `trading` event carries another `fingerprint`, the list changed, so read it again. content: application/json: schema: $ref: '#/components/schemas/AccountMarketsResponse' '400': description: The provider or account is unknown, or no provider is connected. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '401': description: The key is missing, unknown or revoked. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '503': description: The account's markets couldn't be read. Try again shortly. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - tradingApiKey: [] - connectApiKey: [] trader: [] - venueKey: [] trader: [] x-codeSamples: - lang: javascript label: TypeScript source: >- const res = await fetch('https://app.trdrs.co/api/account/markets?provider=rithmic&account=PA-4821-07', { headers: { Authorization: `Bearer ${process.env.TRDRS_API_KEY}` }, }) const data = await res.json() - lang: shell label: cURL source: >- curl 'https://app.trdrs.co/api/account/markets?provider=rithmic&account=PA-4821-07' \ -H "Authorization: Bearer $TRDRS_API_KEY" components: schemas: AccountMarketsResponse: type: object description: >- Every market the account can enter now, by the same judgment its orders meet. properties: account: type: string description: The account number the markets are for. scope: oneOf: - $ref: '#/components/schemas/AccountScope' - type: 'null' description: >- Whose markets they are, or null for a trader's own Demo, which trades every market on the paper book. fingerprint: type: string description: >- Changes whenever the list does. The account stream's `trading` event carries it, so read the list again only when it changes. markets: type: array items: $ref: '#/components/schemas/AccountMarket' description: The markets. required: - account - scope - fingerprint - markets example: account: PA-4821-07 scope: provider: rithmic name: Apex venue: null fingerprint: 3f9a1c27b84e05d6 markets: - market: CME:ES1! symbol: ES1! name: E-mini S&P 500 continuous front month exchange: CME type: future contract: CME:ESU2026 rollAt: '2026-09-09T22:00:00.000Z' - market: CME:ES2! symbol: ES2! name: E-mini S&P 500 continuous second month exchange: CME type: future contract: CME:ESZ2026 rollAt: '2026-09-09T22:00:00.000Z' - market: CME:ESU2026 symbol: CME:ESU2026 name: E-mini S&P 500 Sep 2026 exchange: CME type: future contract: CME:ESU2026 rollAt: '2026-09-09T22:00:00.000Z' - market: CME:ESZ2026 symbol: CME:ESZ2026 name: E-mini S&P 500 Dec 2026 exchange: CME type: future contract: CME:ESZ2026 rollAt: '2026-12-09T23:00:00.000Z' 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 AccountScope: type: object description: >- Whose markets the account trades, as a symbol search names them: the venue that issued the account, the brand of the system a login belongs to (`Apex` for a Rithmic login at Apex), or else the provider. properties: provider: type: string description: >- The provider the account trades through (`hyperliquid`, `rithmic`, `paper`). name: type: string description: The name the account's markets go by. venue: type: - object - 'null' description: >- The venue that issued the account, with its brand, or null for an account no venue issued. properties: id: type: string description: The venue's id. name: type: string description: The venue's name. logoUrl: type: - string - 'null' description: The venue's logo, or null. logoBleed: type: boolean description: True when the logo is meant to fill its frame edge to edge. required: - id - name - logoUrl - logoBleed required: - provider - name - venue example: provider: rithmic name: Apex venue: null AccountMarket: type: object description: 'One market the account trades: a row of its symbol search.' properties: market: type: string description: >- The market key, which symbol search rows and symbol-info carry as `market`, so a row from any feed is matched to it. symbol: type: string description: >- The symbol the catalog names the market by, which a chart loads (`ES1!`, `CME:ESZ2026`, `HYPERLIQUID:BTC`). name: type: string description: The display name. exchange: type: string description: >- The market the symbol lists on: the exchange for a future (`CME`) or the crypto exchange for a perpetual (`Hyperliquid`). A CFD names the provider that serves its price. It never names the account. type: type: string description: >- The class, with the values symbol search returns (`future`, `crypto`, `fx`, `equity`, `commodity`), so a symbol picker filters these rows and picks their icons the same way. contract: type: - string - 'null' description: >- The instrument an order on the market trades: for a continuous future, the dated contract its position names now (`CME:ESZ2026` for `ES1!`), and the market itself otherwise. Null for a continuous future whose contract only the provider names, which `GET /api/trading/match` answers. rollAt: type: - string - 'null' format: date-time description: >- When `contract` changes: a dated contract's roll, and for a continuous future the roll of its front contract, when each position moves on to the next contract. Null where nothing rolls or the contract is not named here. required: - market - symbol - name - exchange - type - contract - rollAt example: market: CME:ES1! symbol: ES1! name: E-mini S&P 500 continuous front month exchange: CME type: future contract: CME:ESU2026 rollAt: '2026-09-09T22:00:00.000Z' securitySchemes: tradingApiKey: type: http scheme: bearer description: >- The Trading API key (`trdrs_sk_…`), for market data, orders and account state on the accounts its owner holds. Use it server-to-server, and keep it on your server. Its scope is named `trading` in the API. connectApiKey: type: http scheme: bearer description: >- A Connect app's API key (`trdrs_ck_sandbox_…` or `trdrs_ck_production_…`), in preview. It belongs to one app in one environment, has a name and an expiry, and carries the whole Connect API. An owner of the app creates it in the Connect dashboard. It creates, reads and closes the app's Connect links under `/api/connect/links`, and on the account, market and trading routes it reads the app's own traders' accounts and market data and routes their orders, each request naming its trader in `x-trdrs-trader`. It stops working when it is revoked or expires, or when the owner who created it stops being an owner. Keep it on your server. trader: type: apiKey in: header name: x-trdrs-trader description: >- Your own id for one of your traders: the id your Connect links name, or the id the accounts your venue issues them use. Send it with your app's API key, or with your Venue key carrying `trader:read`, or `trader:trade` to also route the trader's orders, and the request runs as that trader on their own accounts. An id that names none of your traders is refused with `404` `trader_not_found` and a suspended trader with `403` `trader_suspended`. A request that also carries a cookie or a browser `Origin` is refused with `400` `credential_not_allowed`. 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.