> ## 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 built-in providers and how each is signed into > Returns the six built-in providers (Rithmic, Tastytrade, Hyperliquid, Binance, Bybit and the trdrs paper book) with the login style each declares. Connect draws its grid from this list and shows one form per login style, so the list is also what tells an embedding page which providers exist. Deliberately keyless and static: the declarations are not secret, and a page deciding what to show has not signed anyone in yet. Every tile on the Connect firm list carries the same `loginStyle`, derived from its provider. The values are additive: a new provider or style is appended, none is renamed. ## OpenAPI ````yaml /partner-platform/openapi.json get /api/connect/providers 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/connect/providers: get: tags: - Connect summary: List the built-in providers and how each is signed into description: >- Returns the six built-in providers (Rithmic, Tastytrade, Hyperliquid, Binance, Bybit and the trdrs paper book) with the login style each declares. Connect draws its grid from this list and shows one form per login style, so the list is also what tells an embedding page which providers exist. Deliberately keyless and static: the declarations are not secret, and a page deciding what to show has not signed anyone in yet. Every tile on the Connect firm list carries the same `loginStyle`, derived from its provider. The values are additive: a new provider or style is appended, none is renamed. responses: '200': description: The built-in providers, in registry order content: application/json: schema: $ref: '#/components/schemas/ConnectProvidersResponse' x-codeSamples: - lang: javascript label: TypeScript source: >- const res = await fetch('https://app.trdrs.co/api/connect/providers', { headers: { Authorization: `Bearer ${process.env.TRDRS_API_KEY}` }, }) const data = await res.json() - lang: shell label: cURL source: |- curl 'https://app.trdrs.co/api/connect/providers' \ -H "Authorization: Bearer $TRDRS_API_KEY" components: schemas: ConnectProvidersResponse: type: object properties: providers: type: array items: $ref: '#/components/schemas/ConnectProvider' required: - providers example: providers: - provider: rithmic name: Rithmic loginStyle: trader_login needsSystem: true - provider: tastytrade name: Tastytrade loginStyle: oauth needsSystem: false - provider: hyperliquid name: Hyperliquid loginStyle: wallet_key needsSystem: false - provider: binance name: Binance loginStyle: api_key needsSystem: false - provider: bybit name: Bybit loginStyle: api_key needsSystem: false - provider: paper name: trdrs paper book loginStyle: none needsSystem: false ConnectProvider: type: object description: >- One built-in provider as Connect lists it, with the login style it declares. properties: provider: type: string enum: - rithmic - tastytrade - hyperliquid - binance - bybit - paper description: >- The provider id. It is also the value `?broker=` takes on the trading and account routes. name: type: string description: The product name. loginStyle: type: string enum: - trader_login - oauth - api_key - wallet_key - firm_credentials - none description: >- How the provider is signed into. `trader_login`: the trader’s own username and password at the provider. `oauth`: the trader authorizes at the provider. `api_key`: an API key and secret. `wallet_key`: a wallet address and an agent key. `firm_credentials`: the venue connects it with the firm’s own credentials and the trader types nothing. `none`: no login of its own; signing in to trdrs is the login. needsSystem: type: boolean description: >- True when a trader login belongs to a named system (the trader’s firm), which the form then asks for. Rithmic only today. required: - provider - name - loginStyle - needsSystem ````