Parties and counterparties
GET /v2/parties reads the workspace entity register. Its types array distinguishes:
A non-self entity can be both
client and counterparty. The counterparty API uses the same underlying entity register. Its singular type, such as vendor or customer, describes a business relationship and is different from the register’s types array. Avoid creating the same organization once through each API.
GET /v2/counterparties excludes self and returns summaries. Addresses require include_addresses=true; the counterparty onboarding guide covers addresses and the full detail record.
The Data API’s /v2/entities is public labeled-organization discovery. Its results are distinct from your workspace’s /v2/parties register.
Accounts and groups
Persisted accounts haveentity_id for their owner and an inline entity summary. GET /v2/accounts lists workspace accounts; GET /v2/parties/{id}/accounts restricts the list to one entity.
PUT /v2/parties/{id}/accounts changes ownership. An add operation moves an account to that entity; a remove operation moves it back to self. Removing the attachment does not delete the account. Retain the account’s returned ID and read it back to verify its entity_id.
Groups organize accounts. GET /v2/groups lists those groups, and an account’s groups array records its memberships. Membership and entity ownership are separate relationships.
Connections
A connection records an integration source and its configuration. An account linked to one carriesdetails.connection_id and details.connection_object_id: the Range connection ID and the provider’s object identifier. Standalone onchain accounts do not need connection details.
Connection kind distinguishes account, books, ledger, risk, and travel_rule. Only the account family is an account source. See Connections and providers for capabilities and verification evidence.
Identifiers
Use returned identifiers rather than names or example UUIDs. For event kinds, decimal amounts, directions, and freshness, see Working with responses.