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 loginis stored — you receive the login email in theaccount.importedwebhook (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).
Authorizations
JWT Bearer token for user session auth. Format: "Bearer {token}". Used by User and Organization endpoints.
Query Parameters
Exact match on your customer ID
255DEPRECATED alias for customerId — use customerId instead.
255Partial match on the bound Hyperprop login email
x >= 11 <= x <= 100Related topics
Rebind a customer to a new Hyperprop login (support flow)Create a trading accountUnlink a trader (issues a fresh import key)Bulk-create unlinked accounts with import keysImport a trading account with an import key