> ## 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. # Create evaluation accounts > Creates up to 20 evaluation accounts on the trdrs venue in one call. Each item names a trader by their trdrs sign-in email (the trader must already have signed up; issuing accounts never creates users), the starting balance in whole dollars, and your own `referenceId` for that item. The batch answers 200 with one result per item, in order: an unknown email fails its own item (`ok: false, error: no_user_with_that_email`) and never voids the items around it, so check every result, not just the status code. A malformed request — bad JSON, a missing field, a duplicate `referenceId` within the batch — is a 400 and nothing is created, because malformed input is a pipeline bug, not a business outcome. The trader sees the account in their trdrs account list immediately; a `provision` row lands on the balance ledger. Served when this deployment runs the prop engine; otherwise every route in this group answers 404. Idempotent: per item on your `referenceId` — re-posting a reference your firm already used returns the original account with `created: false` instead of creating a second one, which is what makes the call safe to retry after a crash or timeout. ## OpenAPI ````yaml /partner-platform/openapi.json post /api/partner/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: Market data description: >- Symbol search and resolution, OHLCV history, quote snapshots, the server clock, and the live bar stream. Crypto rides each venue’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 firm 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 surface: 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 broker account (or creates a free demo account) in the app, and firms create evaluation accounts through the Partner API (Firm accounts → Create evaluation accounts) or register venue accounts through Connect (Create an account registration). Account state and the durable ledgers: balances, positions, working orders, fills, P&L history, and the live account stream. - name: Connect description: >- trdrs Connect account registration, for partner firms. Register an account you issued on your own venue — a pending account registration — with the trader’s sign-in email, optionally the venue account id and the login name your venue issued. The trader finds it waiting in the connect flow the moment they sign in with that email: the connect step is pre-filled with everything except the credential, which the trader always enters themselves. A registration never transmits a password and never grants access to anything before the trader’s own login succeeds. These routes answer a partner-scoped key only; a firm API key or a user session gets 401. Registrations expire after 30 days; re-registering the same email + account refreshes the expiry instead of duplicating. The end-to-end flow guide is **[Quick Start](/docs/guides/quick-start)**. - name: Firm accounts description: >- Evaluation accounts your firm issues on the trdrs venue, through your partner key — the other half of account setup. Connect registrations hand off accounts that exist on your venue; these routes create and manage accounts on ours: 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: Webhooks description: >- 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 brokers and prop firms alike: the account-registration (`registration.*`) events fire wherever Connect does, and the account events fire where the prop engine runs. - name: Challenges description: >- The prop evaluation surface: 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 firm-console/admin half of this surface is deliberately not documented here. It is back office, not licensed surface. paths: /api/partner/accounts: post: tags: - Firm accounts summary: Create evaluation accounts description: >- Creates up to 20 evaluation accounts on the trdrs venue in one call. Each item names a trader by their trdrs sign-in email (the trader must already have signed up; issuing accounts never creates users), the starting balance in whole dollars, and your own `referenceId` for that item. The batch answers 200 with one result per item, in order: an unknown email fails its own item (`ok: false, error: no_user_with_that_email`) and never voids the items around it, so check every result, not just the status code. A malformed request — bad JSON, a missing field, a duplicate `referenceId` within the batch — is a 400 and nothing is created, because malformed input is a pipeline bug, not a business outcome. The trader sees the account in their trdrs account list immediately; a `provision` row lands on the balance ledger. Served when this deployment runs the prop engine; otherwise every route in this group answers 404. Idempotent: per item on your `referenceId` — re-posting a reference your firm already used returns the original account with `created: false` instead of creating a second one, which is what makes the call safe to retry after a crash or timeout. requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/PartnerAccountsCreateRequest' responses: '200': description: Per-item results, in request order (PartnerAccountsCreateResponse) content: application/json: schema: $ref: '#/components/schemas/PartnerAccountsCreateResponse' '400': description: >- Malformed input — bad JSON, a field out of range, or a duplicate referenceId within the batch. Nothing was created. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '401': description: The bearer is not a partner-scoped key for an active partner firm content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: Issuing accounts is not enabled on this deployment content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - partnerKey: [] x-codeSamples: - lang: javascript label: TypeScript source: >- const res = await fetch('https://app.trdrs.co/api/partner/accounts', { method: 'POST', headers: { 'content-type': 'application/json', Authorization: `Bearer ${process.env.TRDRS_API_KEY}`, }, body: JSON.stringify({ "accounts": [ { "email": "trader@example.com", "startingBalance": 50000, "referenceId": "order-84117" }, { "email": "second@example.com", "startingBalance": 100000, "referenceId": "order-84118" } ] }), }) const data = await res.json() - lang: shell label: cURL source: |- curl -X POST 'https://app.trdrs.co/api/partner/accounts' \ -H "Authorization: Bearer $TRDRS_API_KEY" \ -H 'content-type: application/json' \ -d '{"accounts":[{"email":"trader@example.com","startingBalance":50000,"referenceId":"order-84117"},{"email":"second@example.com","startingBalance":100000,"referenceId":"order-84118"}]}' components: schemas: PartnerAccountsCreateRequest: type: object description: >- PartnerAccountsCreateRequest. A batch of 1 to 20 accounts to issue on the trdrs venue; each item carries your own referenceId, so a retried batch re-answers instead of re-creating. properties: accounts: type: array minItems: 1 maxItems: 20 items: type: object properties: email: type: string description: >- The trader’s trdrs sign-in email. The trader must already hold a trdrs account — issuing accounts never creates users. startingBalance: type: integer description: >- Whole dollars, 1000–10000000: the account’s starting balance, and what a reset returns it to. referenceId: type: string description: >- Your idempotency handle for this item (≤80 chars, unique within your firm). Re-posting the same reference returns the original account with `created: false`. required: - email - startingBalance - referenceId required: - accounts example: accounts: - email: trader@example.com startingBalance: 50000 referenceId: order-84117 - email: second@example.com startingBalance: 100000 referenceId: order-84118 PartnerAccountsCreateResponse: type: object description: >- PartnerAccountsCreateResponse. One result per requested item, in request order. An `ok: false` item names its reason and never voids the items around it — check every result, not just the status code. properties: firm: type: string description: Your firm’s name, as trdrs holds it. results: type: array description: Per-item outcomes, in the order you sent them. items: type: object properties: referenceId: type: string description: Echoed from your request item. email: type: string description: Echoed from your request item (lowercased). ok: type: boolean accountNumber: type: string description: >- The issued account (present when ok). Trades on trdrs under this number. balance: type: number description: >- The account’s current balance (present when ok) — the starting balance on a fresh create. created: type: boolean description: >- True on a fresh create; false when your referenceId already owned this account (the idempotent re-answer). error: type: string enum: - no_user_with_that_email description: >- Present when ok is false. `no_user_with_that_email`: nobody has signed in to trdrs with that email yet — have the trader sign up first, then re-post the same referenceId. required: - referenceId - email - ok required: - firm - results example: firm: yourfirm results: - referenceId: order-84117 email: trader@example.com ok: true accountNumber: EVAL-7C21A9 balance: 50000 created: true - referenceId: order-84118 email: second@example.com ok: false error: no_user_with_that_email ErrorResponse: type: object properties: error: type: string required: - error example: error: invalid_instrument securitySchemes: partnerKey: type: http scheme: bearer description: >- A partner-scoped API key (`trdrs_sk_…`), issued to a trdrs Connect partner firm and accepted only under `/api/partner/`. Same format as the firm (`tenant`) key, different scope: a firm API key is refused here, and this key is refused everywhere else. ````