API reference: Accounts. Opens on the public documentation site in a new tab.
Where it disagrees with this page, this page is authoritative for the partner surface.
Your two firms
If you are an IB, this differs.
You get three identities, not two: the participant firm, the clearing-member firm, and an
IB anchor DCO account, which is not the clearing-member firm. Record and label all three.
Using a DCO clearing-member ID where a DCM firm name belongs stalls onboarding with no error
returned to you. The physical-person legal-name rule also bites at the moment you record these
strings — see Naming and record requirements.
The two strings differ only in the suffix:
-api-participant versus -api-clearing-member. We give you both strings at your credential gate — record both, and do not construct either. What the leading digits mean is not published; do not read a date, an ordering or anything else out of them.
Legacy examples show three different prefix shapes —
firms/ISV-Participant-YourFirmID/...,
firms/ISV-YourFirmID/... and firms/ISV-Example-ClearingMember/... — with no explanation. None of
them is the real shape. Use the two strings we gave you, verbatim.whoami returns the wrong firm for this purpose
GET /v1/whoami resolves your clearing-member firm (ep3_account_firm_name), not your participant firm (ep3_participant_firm_name). It is the right call for “which firm is this token”, and the wrong basis for addressing a user.
Concretely, what happens when you build a participant ID from the whoami firm and send it:
- The request fails
validateParticipantFirmOwnership. - It raises
CROSS_ISV_PARTICIPANT_IMPERSONATION_ATTEMPT— a CRITICAL security log entry. - It increments a cross-ISV access metric, against your firm, as a legitimate partner.
Where a participant ID actually comes from
The authoritative sources are two, and both come from KYC:participantIdon thekyc.approvedwebhook, orparticipantIdfromGET /v1/kyc/statusafter a decision ofACCEPT.
x-participant-id for the life of that user.
GET /v1/users does not solve this. It is a roster read: it is account-scoped and requires x-participant-id itself, so it cannot be used to discover your first participant ID. There is no bootstrap listing.
One SSN is one account, platform-wide
A trading account ID is derived from the end user’s SSN, and one SSN maps to exactly one exchange account across the entire platform — the same rule the Polymarket mobile app enforces. Give every preprod test user a distinct SSN from your own fixture set, and record which user holds which.provisionedAccount is opaque
provisionedAccount is the fully-qualified DCM account name. Its account identifier is opaque and cannot be derived from participant or user data. Store the string we return; never assemble it.
Legacy examples showing firms/.../accounts/user-123-trading teach the wrong model — they imply the account segment is your user ID, and it is not.
Where x-participant-id goes
An account-scoped read, end to end
Each snippet imports the canonical token client from Authentication.authorization. Note the field-naming split you will hit across surfaces: KYC requests are snake_case, REST responses are camelCase, and webhooks are snake_case.