> ## Documentation Index > Fetch the complete documentation index at: https://docs.hyperprop.com/llms.txt > Use this file to discover all available pages before exploring further. # Get trading accounts for your organization > Retrieve all trading accounts for your organization with powerful filtering and search. **What is a trading account?** A trading account represents a trader's evaluation or sim-funded account. Each account tracks their progress, balance, and performance against your trading rules. **Account types:** | Type | Description | |------|-------------| | `evaluation` | Challenge account where trader must hit profit target | | `sim_funded` | Simulated funded account after passing evaluation | **Account statuses:** | Status | Description | |--------|-------------| | `not_started` | Account created but trader hasn't begun trading | | `in_progress` | Trader is actively trading | | `passed` | Trader hit profit target and passed the evaluation | | `failed` | Trader violated a rule (max loss, drawdown, etc.) | | `expired` | Evaluation period ended without passing | **What you get for each account:** - Account details (number, type, status, balances) - Performance data and high water mark - Trading plan and rules applied - Trader info (your customer's email and name) - Linked Hyperprop user (or the one-time `importKey` while still unlinked) - Purchase details (what they paid) - Custom metadata (any JSON data you need) **Search:** The `search` parameter is flexible and matches: - Account number (partial match): `?search=APEX-100K` - Trader email (partial match): `?search=john@` - Trader name (partial match): `?search=John` - Account ID (exact match): `?search=7c9e6679-7425-40de-944b-e07fc1f90ae7` - User ID (exact match): `?search=f994bc02-343c-4026-8a57-afc085eca8d5` **Lookup by your own customer ID:** `?customerId=mffu-cust-4471` returns all accounts of the customer whose `customerId` you set at creation (or via PATCH) — an indexed, exact-match, deterministic lookup for reconciliation. (`?externalRef=` still works as a deprecated alias.) **Example queries:** ```http # Find all active evaluations GET /organization/trading-accounts?type=evaluation&status=in_progress # Search for a specific trader GET /organization/trading-accounts?search=john@example.com # Get all passed accounts this month GET /organization/trading-accounts?status=passed&startDate=2025-01-01&endDate=2025-01-31 # Find high-priority accounts that are in progress GET /organization/trading-accounts?metadata=priority:high&status=in_progress # Page through results (page 2, 25 per page) GET /organization/trading-accounts?limit=25&offset=25 ``` **Use cases:** - Monitor active evaluations in real-time - Find accounts for a specific trader - Generate pass/fail reports - Track VIP or promotional accounts - Audit account history for compliance ## OpenAPI ````yaml /api-reference/openapi.json get /v1/organization/trading-accounts openapi: 3.0.0 info: title: Hyperprop Platform API version: 1.0.0 description: >- REST API for the Hyperprop Trading Platform — provision evaluation and funded trading accounts, manage traders and plans, react to account lifecycle events via signed webhooks, and reconcile billing. Built for prop firms integrating from their own backend. ## Authentication Two methods, depending on who is calling: ### Bearer Token (JWT) — users & dashboard Most endpoints accept a JWT via `Authorization: Bearer `. Used by the dashboard and client applications. ### API Key — organizations (prop firms) Organization endpoints also accept `X-API-Key: hp_live_...` for programmatic access from your backend — no browser session needed. Keys are managed by organization admins in the dashboard; each key carries permissions (`read`, `write`, `admin`) and can be rotated or revoked at any time. Keys are stored hashed (SHA-256) — the raw key is shown once at creation. Endpoints that create or modify data require `write` or `admin`. ## Quick Start ```bash # 1. List your trading plans (grab a tradingPlanId) curl "https://api.hyperprop.com/platform/v1/organization/trading-plans" \ -H "X-API-Key: hp_live_your_key_here" # 2. Create a trading account for a trader (by Hyperprop user ID or email) curl -X POST "https://api.hyperprop.com/platform/v1/organization/trading-accounts" \ -H "X-API-Key: hp_live_your_key_here" \ -H "Content-Type: application/json" \ -d '{"type": "evaluation", "tradingPlanId": "", "email": "trader@example.com"}' ``` ## Response Envelope & Error Handling **Success** responses always wrap the payload: ```json { "success": true, "data": { ... }, "message": "optional human-readable note" } ``` **Errors** — including request-validation failures, auth failures, and errors proxied from the trade engine — always return this single uniform shape with a machine-readable `code` you can switch on: ```json { "success": false, "statusCode": 404, "error": "Not Found", "message": "No Hyperprop user found with that email. The trader must have a Hyperprop account before an account can be created for them.", "code": "TRADER_NOT_FOUND" } ``` Parse rule of thumb: check `success`; on `false`, switch on `code` (never on `message` text — messages can be reworded). Some errors carry additional structured context alongside these fields (e.g. payout rejections include a `consistency` block). Common codes: `VALIDATION_ERROR` (malformed payload/params), `UNAUTHORIZED`, `INSUFFICIENT_PERMISSIONS` / `NOT_ADMIN` (key lacks write/admin), `*_NOT_FOUND` (missing resource), `*_NOT_IN_ORG` (resource belongs to another organization), `IDEMPOTENCY_KEY_IN_PROGRESS` (duplicate in flight), `ENGINE_UNREACHABLE` (trade engine down — retry with the same idempotency key). Endpoint-specific codes (e.g. payout `OPEN_EXPOSURE`, `CONSISTENCY_BLOCKED`) are documented on each endpoint. ## Idempotency **Every mutating endpoint (POST, PUT, PATCH, DELETE) honors idempotency keys uniformly.** Send an `Idempotency-Key` header (the `X-Idempotency-Key` spelling is accepted as an alias) to retry any write safely without creating duplicates. How it works: - The key is scoped to your organization + the request path. The first request with a given key executes normally and its response is cached for **24 hours**. - A replay (same key, same path) within 24 hours returns the cached response with an `Idempotency-Replayed: true` response header — the operation is **not** executed again. - If a request with the same key is still in flight, the duplicate gets `409 IDEMPOTENCY_KEY_IN_PROGRESS` — back off and retry; you'll then receive the cached response. - 5xx responses are **not** cached, so retrying after a server error re-executes the request (that's what you want). 2xx-4xx responses are cached — if a request failed validation and you fix the payload, use a **fresh key**. - Keys are free-form strings up to 255 characters. Use something that identifies the operation on your side, e.g. `order-8814-attempt-1`. ```bash curl -X POST "https://api.hyperprop.com/platform/v1/organization/trading-accounts" \ -H "X-API-Key: hp_live_your_key_here" \ -H "Idempotency-Key: order-8814-attempt-1" \ -H "Content-Type: application/json" \ -d '{"type": "evaluation", "tradingPlanId": "...", "traderId": "..."}' ``` This applies to account creation, account PATCH (status, currentBalance, metadata), rules, plans, lockouts, payouts, team, webhooks — every write on the platform API. Payouts additionally forward the key to the trade engine for engine-level double-withdrawal protection. ## Pagination & Sorting List endpoints support both styles: - **Cursor (recommended):** pass `?cursor=` from the previous response's `pagination.nextCursor`. Stable under concurrent writes. - **Offset:** `?limit=&offset=` with `pagination.total` / `hasMore` in the response. Sorting uses `?sort=field:direction` (e.g. `?sort=created_at:asc`); allowed fields are listed per endpoint. Default: `created_at:desc`. ## Custom Metadata Trading accounts, purchases, traders, plans, and rules all carry a free-form `metadata` JSON object. Use it to store your own references — payment IDs, campaign tags, payout records, internal notes. Hyperprop stores and returns it verbatim (and lets you filter list endpoints by it, e.g. `?metadata=stripePaymentId:pi_123`) but never interprets it. Update endpoints support `mergeMetadata: true` for shallow (top-level) merges instead of wholesale replacement. ## Webhooks Subscribe to account lifecycle events (`account.created`, `account.status_changed`, `account.updated`, `account.passed`, `account.failed`, and more) via the Webhooks endpoints. Deliveries are HMAC-SHA256 signed — verify `X-Hyperprop-Signature` with your endpoint secret, using `X-Hyperprop-Timestamp` for replay protection; `X-Hyperprop-Delivery` gives you a unique delivery ID for deduplication. Failed deliveries are retried with backoff, and you can redeliver any event from the dashboard or API. ## MCP Connector (AI Agents) The platform ships a built-in [MCP](https://modelcontextprotocol.io) server, so AI agents and assistants (Claude, Cursor, custom agents) can operate your organization directly — no integration code required. ```http Endpoint: POST https://api.hyperprop.com/platform/v1/mcp Transport: Streamable HTTP (stateless, JSON responses) Auth: X-API-Key header, Authorization: Bearer hp_live_..., or OAuth ``` **Claude web / desktop (Add custom connector):** paste the endpoint URL and leave the OAuth Client ID/Secret fields empty — the connector registers itself automatically. Claude opens a Hyperprop consent page where an org admin pastes the organization API key once; access then follows that key's permissions and ends if the key is revoked. (Under the hood: OAuth 2.1 with PKCE and dynamic client registration.) **Cursor / Claude Code — `mcp.json`:** ```json { "mcpServers": { "hyperprop": { "url": "https://api.hyperprop.com/platform/v1/mcp", "headers": { "X-API-Key": "hp_live_your_key_here" } } } } ``` **Available tools (12):** `list_trading_plans`, `list_trading_accounts`, `get_trading_account`, `get_account_audit_log`, `list_traders`, `get_trader`, `list_purchases`, `get_purchase`, `get_billing_summary` (read) · `create_trading_account`, `update_trading_account`, `record_payout` (write). Every tool call executes the corresponding REST endpoint with your key, so organization scoping, permissions, validation, audit logging, and webhooks apply exactly as documented on each endpoint. Read tools work with any key; write tools need `write`/`admin` permission — connect a **read-only key** if you want a strictly read-only agent. `create_trading_account` accepts an optional `idempotencyKey` so agent retries can't create duplicates, and `record_payout` implements the documented payout recipe (append to `metadata.payouts`, adjust `currentBalance`, audit-logged `reason`). ## Endpoint Groups - **Authentication** — Sign up, sign in, OAuth, MFA, password reset. No auth required for most. - **User** — Profile, notifications, demo accounts, audit logs. Requires **Bearer token** (JWT). - **Organization** — Trading accounts, plans, rules, traders, purchases, lockouts, billing, bulk operations, webhooks, analytics. Accepts **Bearer token** OR **API Key**. - **System** — Health checks. No auth required. x-logo: url: https://app.hyperprop.com/logo-icon.svg altText: Hyperprop href: https://hyperprop.com servers: - url: https://api.hyperprop.com/platform description: Production security: [] tags: - name: Authentication description: >- User authentication - signup, signin, signout, password reset, email verification, OAuth, and MFA - name: User description: >- User account management - profile, notifications, agreements, dismissals, and audit logs. Requires Bearer token. - name: Organization description: >- Organization management - profile, team, trading accounts, plans, and rules. Supports **dual authentication**: Bearer JWT token (dashboard users) OR X-API-Key (programmatic access). - name: Demo description: >- Demo account management - import, list, and delete demo trading accounts. Requires Bearer token. - name: Market Data description: CME futures contracts and market data. Requires Bearer token. - name: System description: System endpoints - health checks and connectivity paths: /v1/organization/trading-accounts: get: tags: - Organization summary: Get trading accounts for your organization description: >- Retrieve all trading accounts for your organization with powerful filtering and search. **What is a trading account?** A trading account represents a trader's evaluation or sim-funded account. Each account tracks their progress, balance, and performance against your trading rules. **Account types:** | Type | Description | |------|-------------| | `evaluation` | Challenge account where trader must hit profit target | | `sim_funded` | Simulated funded account after passing evaluation | **Account statuses:** | Status | Description | |--------|-------------| | `not_started` | Account created but trader hasn't begun trading | | `in_progress` | Trader is actively trading | | `passed` | Trader hit profit target and passed the evaluation | | `failed` | Trader violated a rule (max loss, drawdown, etc.) | | `expired` | Evaluation period ended without passing | **What you get for each account:** - Account details (number, type, status, balances) - Performance data and high water mark - Trading plan and rules applied - Trader info (your customer's email and name) - Linked Hyperprop user (or the one-time `importKey` while still unlinked) - Purchase details (what they paid) - Custom metadata (any JSON data you need) **Search:** The `search` parameter is flexible and matches: - Account number (partial match): `?search=APEX-100K` - Trader email (partial match): `?search=john@` - Trader name (partial match): `?search=John` - Account ID (exact match): `?search=7c9e6679-7425-40de-944b-e07fc1f90ae7` - User ID (exact match): `?search=f994bc02-343c-4026-8a57-afc085eca8d5` **Lookup by your own customer ID:** `?customerId=mffu-cust-4471` returns all accounts of the customer whose `customerId` you set at creation (or via PATCH) — an indexed, exact-match, deterministic lookup for reconciliation. (`?externalRef=` still works as a deprecated alias.) **Example queries:** ```http # Find all active evaluations GET /organization/trading-accounts?type=evaluation&status=in_progress # Search for a specific trader GET /organization/trading-accounts?search=john@example.com # Get all passed accounts this month GET /organization/trading-accounts?status=passed&startDate=2025-01-01&endDate=2025-01-31 # Find high-priority accounts that are in progress GET /organization/trading-accounts?metadata=priority:high&status=in_progress # Page through results (page 2, 25 per page) GET /organization/trading-accounts?limit=25&offset=25 ``` **Use cases:** - Monitor active evaluations in real-time - Find accounts for a specific trader - Generate pass/fail reports - Track VIP or promotional accounts - Audit account history for compliance operationId: getV1OrganizationTradingaccounts parameters: - description: Search by account number, trader email/name, account ID, or user ID name: search in: query required: false schema: type: string - description: Filter by account type name: type in: query required: false schema: type: string enum: - evaluation - sim_funded - competition - description: Filter by account status name: status in: query required: false schema: type: string enum: - not_started - in_progress - passed - failed - expired - description: Filter by metadata key:value (e.g., "vip:true", "source:affiliate") name: metadata in: query required: false schema: type: string - description: >- Exact match on the customerId you set at account creation (or via PATCH). Deterministic lookup of all accounts belonging to one of your customers. name: customerId in: query required: false schema: type: string maxLength: 255 - description: DEPRECATED alias for customerId — use customerId instead. name: externalRef in: query required: false schema: type: string maxLength: 255 - description: >- true = only accounts with no trader attached yet (their one-time importKey is included in each row); false = only linked accounts. Omit for both. name: unlinked in: query required: false schema: type: boolean - description: Only include accounts created from this date onwards x-format: isoDate: true name: startDate in: query required: false schema: type: string - description: Only include accounts created up to this date x-format: isoDate: true name: endDate in: query required: false schema: type: string - description: 'Results per page (default: 50, max: 100)' name: limit in: query schema: type: integer minimum: 1 maximum: 100 default: 50 - description: Skip this many results (for pagination) name: offset in: query schema: type: integer minimum: 0 default: 0 - description: >- Cursor for pagination. Pass the `nextCursor` value from the previous response to get the next page. When using cursor, do not send `offset` — it will be ignored. **How it works:** The cursor is an opaque string that points to the last item you received. The server uses it to efficiently fetch the next set of results without scanning previous pages. **Backwards compatible:** If you don't send a cursor, offset/limit pagination works as before. name: cursor in: query required: false schema: type: string responses: '200': description: Success - Returns paginated list of trading accounts content: '*/*': schema: $ref: '#/components/schemas/Model123' '401': description: Unauthorized - Invalid or missing session token content: '*/*': schema: $ref: '#/components/schemas/Model124' '403': description: Forbidden - Your account is not associated with an organization content: '*/*': schema: $ref: '#/components/schemas/Model125' '500': description: An unexpected error occurred content: '*/*': schema: $ref: '#/components/schemas/Model3' security: - Bearer: [] - X-API-Key: [] components: schemas: Model123: type: object properties: success: type: boolean example: true data: $ref: '#/components/schemas/Model122' Model124: type: object properties: statusCode: type: number example: 401 error: type: string example: Unauthorized message: type: string example: Invalid or expired session Model125: type: object properties: statusCode: type: number example: 403 error: type: string example: Forbidden message: type: string example: This endpoint is only available for organization users code: type: string example: NOT_ORGANIZATION_USER Model3: type: object properties: success: type: boolean description: Always false on errors example: false statusCode: type: number example: 500 error: type: string example: Internal Server Error message: type: string example: An unexpected error occurred code: type: string description: Machine-readable error code — switch on this, not on message text example: INTERNAL_ERROR Model122: type: object example: organizationId: a6fcc0ce-eb28-4f43-b256-96a3144b0d34 organizationName: FakePropFirm accounts: - id: 7c9e6679-7425-40de-944b-e07fc1f90ae7 accountNumber: ACC-7845KXPQ type: evaluation status: in_progress initialBalance: 50000 currentBalance: 52150 highWaterMark: 53200 dailyStartingBalance: 51800 startedAt: '2026-02-01T09:00:00.000Z' completedAt: null violationReason: null metadata: source: affiliate_program userId: f994bc02-343c-4026-8a57-afc085eca8d5 userEmail: trader@example.com userAvatarUrl: https://api.dicebear.com/9.x/glass/svg?seed=trader tradingPlan: id: 09c93da5-f057-4cc5-82da-ff9220292c94 name: 50K Challenge accountSize: 50000 tradingRule: id: 6bec94a1-425b-47be-bb41-a80e3140e2e7 name: Standard Rules profitTarget: 4000 maxLoss: 2500 maxDrawdown: 5 drawdownType: static trader: email: john.smith@email.com name: John Smith purchase: id: f47ac10b-58cc-4372-a567-0e02b2c3d479 purchaseDate: '2026-01-28T10:00:00.000Z' pricePaid: 299 currency: USD metadata: stripePaymentId: pi_3ABC123 createdAt: '2026-01-28T10:00:00.000Z' updatedAt: '2026-02-17T14:30:00.000Z' pagination: total: 142 limit: 50 offset: 0 hasMore: true properties: organizationId: type: string description: Your organization ID organizationName: type: string description: Your organization name accounts: $ref: '#/components/schemas/Model120' pagination: $ref: '#/components/schemas/Model121' Model120: type: array description: Array of trading accounts items: $ref: '#/components/schemas/Model119' Model121: type: object properties: total: type: number limit: type: number offset: type: number hasMore: type: boolean nextCursor: type: string description: >- Cursor for the next page. Pass as ?cursor= to get the next set of results. Null if no more results. Model119: type: object properties: id: type: string description: Unique account ID accountNumber: type: string description: Human-readable account number type: type: string description: Account type (evaluation, sim_funded, competition) status: type: string description: Current account status initialBalance: type: number description: Starting balance currentBalance: type: number description: Current balance highWaterMark: type: number description: Highest balance achieved dailyStartingBalance: type: number description: Balance at start of trading day startedAt: type: string description: When trading started completedAt: type: string description: When completed/failed violationReason: type: string description: Reason for failure metadata: $ref: '#/components/schemas/Model117' userId: type: string description: Hyperprop user ID userEmail: type: string description: Hyperprop user email userAvatarUrl: type: string description: User avatar URL tradingPlan: $ref: '#/components/schemas/Model118' tradingRule: $ref: '#/components/schemas/tradingRule' trader: $ref: '#/components/schemas/trader' purchase: $ref: '#/components/schemas/purchase' createdAt: type: string updatedAt: type: string Model117: type: object description: Custom metadata Model118: type: object properties: id: type: string name: type: string accountSize: type: number tradingRule: type: object properties: id: type: string name: type: string profitTarget: type: number maxLoss: type: number maxDrawdown: type: number drawdownType: type: string trader: type: object properties: email: type: string name: type: string purchase: type: object properties: id: type: string purchaseDate: type: string pricePaid: type: number currency: type: string metadata: $ref: '#/components/schemas/changes' changes: type: object securitySchemes: Bearer: type: apiKey name: Authorization in: header description: >- JWT Bearer token for user session auth. Format: "Bearer {token}". Used by User and Organization endpoints. X-API-Key: type: apiKey name: X-API-Key in: header description: >- Organization API key for programmatic access. Format: "hp_live_{key}". Used by Organization endpoints as an alternative to Bearer token. Keys are managed in the dashboard. ```` ## Related topics - [Get trading plans for your organization](/platform-api/organization/get-trading-plans-for-your-organization.md) - [Get trading rules for your organization](/platform-api/organization/get-trading-rules-for-your-organization.md) - [Get a specific trading account](/platform-api/organization/get-a-specific-trading-account.md) - [Get purchases for your organization](/platform-api/organization/get-purchases-for-your-organization.md) - [Get your organization profile](/platform-api/organization/get-your-organization-profile.md)