> ## 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. # List trader identity bindings (customer ⇄ Hyperprop login) > One firm customer, one Hyperprop login. A **binding** pins the `customerId` you set on your accounts to a single Hyperprop login. **How bindings are created (automatic):** - **Unassigned accounts:** the customer redeems the import key with their Hyperprop login, and a binding `customerId ⇄ their Hyperprop login` is stored — you receive the login email in the `account.imported` webhook (`import.importedEmail`) and on the org WebSocket stream, so you can attach it to the customer's profile on your side. - **Directly-linked accounts (`traderId`/`email`):** the binding is created at account creation (`boundVia: "api"`). **What bindings enforce:** Every later import for the same `customerId` must use the SAME Hyperprop login — a different login gets `409 TRADER_ALREADY_BOUND` with a masked hint of the correct email. Likewise, creating a directly-linked account for a bound customer with a different `traderId`/`email` is refused with `409 CUSTOMER_ALREADY_BOUND`. This stops customers from scattering accounts across multiple Hyperprop identities. Since `customerId` is required on every account, every customer is soulbound from their first account onwards. **Bindings are scoped to YOUR organization only.** They never restrict what your customer does at other prop firms: the same Hyperprop login can hold accounts from any number of firms (each firm gets its own binding), and a customer of another firm is free to use a different Hyperprop login there. The rule is strictly: one customer *of yours* = one Hyperprop login *for your accounts*. **Support flow (customer lost their Hyperprop login):** rebind the customer with `POST /trader-bindings/{bindingId}/rebind` (`{ "email": "their-new-login@..." }`). There is no plain release — a customer always has exactly one bound login. Rebinding fails every still-active account on the old login (with an `account.failed` webhook per account) so the old identity can never trade again; terminal accounts keep their history. **Permissions:** any organization member (or API key). ## OpenAPI ````yaml /api-reference/openapi.json get /v1/organization/trader-bindings 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, quick start, error handling, idempotency, pagination, custom metadata, webhooks, and the MCP connector are documented at https://docs.hyperprop.com. 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: Trading accounts description: Create, update, and inspect trading accounts. - name: Traders description: Look up and update the traders in your organization. - name: Trading plans description: Define the plans you sell. - name: Trading rules description: Define how accounts are evaluated. - name: Lockouts description: Pause and resume trading on an account. - name: Payouts description: Check payout eligibility and record payouts. - name: Purchases description: Purchases recorded for your organization. - name: Time Machine description: Restore accounts to an earlier trading day or instant. - name: Webhooks description: Register webhook endpoints and inspect deliveries. - name: Events description: Your organization's event history and real-time event stream. - name: Reconciliation description: Balances, end-of-day snapshots, and fills for reconciliation. - name: Analytics description: Organization performance and plan economics. - name: Billing description: 'Your Hyperprop bill: activity, billing cycles, and forecasts.' - name: Team and roles description: Manage dashboard access for your staff. - name: API keys description: Manage your organization's API key. - name: Logs and health description: API request logs, the audit log, and integration health. - name: Organization profile description: Your organization's profile and logo. - name: Support description: Open and follow up on support tickets. - name: Partner access description: >- Read a trader's journal as an approved partner app, with the trader's own key. paths: /v1/organization/trader-bindings: get: tags: - Traders summary: List trader identity bindings (customer ⇄ Hyperprop login) description: >- One firm customer, one Hyperprop login. A **binding** pins the `customerId` you set on your accounts to a single Hyperprop login. **How bindings are created (automatic):** - **Unassigned accounts:** the customer redeems the import key with their Hyperprop login, and a binding `customerId ⇄ their Hyperprop login` is stored — you receive the login email in the `account.imported` webhook (`import.importedEmail`) and on the org WebSocket stream, so you can attach it to the customer's profile on your side. - **Directly-linked accounts (`traderId`/`email`):** the binding is created at account creation (`boundVia: "api"`). **What bindings enforce:** Every later import for the same `customerId` must use the SAME Hyperprop login — a different login gets `409 TRADER_ALREADY_BOUND` with a masked hint of the correct email. Likewise, creating a directly-linked account for a bound customer with a different `traderId`/`email` is refused with `409 CUSTOMER_ALREADY_BOUND`. This stops customers from scattering accounts across multiple Hyperprop identities. Since `customerId` is required on every account, every customer is soulbound from their first account onwards. **Bindings are scoped to YOUR organization only.** They never restrict what your customer does at other prop firms: the same Hyperprop login can hold accounts from any number of firms (each firm gets its own binding), and a customer of another firm is free to use a different Hyperprop login there. The rule is strictly: one customer *of yours* = one Hyperprop login *for your accounts*. **Support flow (customer lost their Hyperprop login):** rebind the customer with `POST /trader-bindings/{bindingId}/rebind` (`{ "email": "their-new-login@..." }`). There is no plain release — a customer always has exactly one bound login. Rebinding fails every still-active account on the old login (with an `account.failed` webhook per account) so the old identity can never trade again; terminal accounts keep their history. **Permissions:** any organization member (or API key). operationId: getV1OrganizationTraderbindings parameters: - description: Exact match on your customer ID 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: Partial match on the bound Hyperprop login email name: email in: query required: false schema: type: string - name: page in: query schema: type: integer minimum: 1 default: 1 - name: limit in: query schema: type: integer minimum: 1 maximum: 100 default: 25 responses: '200': description: Success content: '*/*': schema: $ref: '#/components/schemas/Model126' '401': description: Authentication required content: '*/*': schema: $ref: '#/components/schemas/Model9' '500': description: An unexpected error occurred content: '*/*': schema: $ref: '#/components/schemas/Model5' security: - X-API-Key: [] components: schemas: Model126: type: object properties: success: type: boolean example: true data: $ref: '#/components/schemas/Model125' Model9: type: object properties: success: type: boolean description: Always false on errors example: false statusCode: type: number example: 401 error: type: string example: Unauthorized message: type: string example: Authentication required code: type: string description: Machine-readable error code — switch on this, not on message text example: UNAUTHORIZED Model5: 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 Model125: type: object properties: bindings: $ref: '#/components/schemas/bindings' pagination: $ref: '#/components/schemas/Model124' bindings: type: array items: $ref: '#/components/schemas/Model123' Model124: type: object properties: total: type: number example: 1 page: type: number example: 1 limit: type: number example: 25 Model123: type: object properties: id: type: string example: a3a3d7c1-... organizationId: type: string customerId: type: string description: Your customer ID example: acme-cust-4471 userId: type: string description: Bound Hyperprop user ID email: type: string description: Bound Hyperprop login email example: trader@example.com boundAt: type: string x-format: isoDate: true boundVia: type: string description: >- "import" (created at import-key redemption) or "api" (created at directly-linked account creation) example: import securitySchemes: X-API-Key: type: apiKey name: X-API-Key in: header description: >- Organization API key. Format: "hp_live_{key}". Organization admins manage the key in the dashboard. ```` ## Related topics - [Rebind a customer to a new Hyperprop login (support flow)](/platform-api/traders/rebind-a-customer-to-a-new-hyperprop-login-support-flow.md) - [Create a trading account](/platform-api/trading-accounts/create-a-trading-account.md) - [Unlink a trader (issues a fresh import key)](/platform-api/trading-accounts/unlink-a-trader-issues-a-fresh-import-key.md) - [Bulk-create unlinked accounts with import keys](/platform-api/trading-accounts/bulk-create-unlinked-accounts-with-import-keys.md) - [Introduction](/introduction.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.