Use the browser to create or reuse your signing identity, log in with your passkey, and approve secure account setup yourself. Reading this guide does not authenticate you.

​
Start here

  1. Open the authentication and secure setup tutorial and check the venue’s current capabilities.
  2. Reuse your existing identity. If you need a new one, follow only a registration flow listed as available.
  3. Complete the tutorial’s browser passkey ceremony yourself. Keep session credentials private.
  4. Before trading, verify your account’s Canton Party binding is active. Login alone does not establish it.
If a capability is unavailable, an approval is refused, or a result is unclear, stop. Follow the tutorial’s recovery guidance rather than repeating registration or signing.

​
Use the API playground

The playground on each API reference page sends real requests. Private routes need a bearer in the playground’s authorization box. To get one in the browser, request an API key for your own account and approve it with your passkey:
  1. In the playground, call POST /v1/agent-connect/start with a clientName of your choice and scopes read, or read and trade. It needs no bearer. The answer carries connectCode, userCode and verificationUrl.
  2. Open verificationUrl, sign in with your passkey, check that the page shows the same userCode, and approve.
  3. Call POST /v1/agent-connect/complete with the connectCode. After your approval it answers approved with apiKey, exactly once, so copy it then. Before your approval it answers authorization_pending. After ten minutes the request expires and you start again.
  4. Paste the apiKey itself into the playground’s authorization box. It works on account and order routes within the scopes you approved.
Deposits and withdrawals do not take an API key; they need your signed-in session, which programs get through the sign-in steps in the introduction. Where the venue’s collateral is USDCx, you deposit an exact amount of the USDCx your Party already holds, with one passkey signature:
  1. Call POST /v1/accounts/:accountId/deposits with { "amount": "1.2345678901" } and an Idempotency-Key header. Repeating the request with the same key returns the same deposit.
  2. The amount keeps every digit up to 10 decimals and is never rounded. A non-zero digit past the 10th decimal answers 409 with rejectionGuard deposit_amount_scale_exceeded; zero answers deposit_amount_invalid, and text that is not a plain decimal answers 400 invalid_request.
  3. Call POST /v1/accounts/:accountId/deposits/confirm with action initiate and the deposit’s depositId. Approve the passkey challenge, then send action complete with the same depositId, signingStep owner_deposit_authorization, the challengeIdentifier and the passkey’s firstFactor. Confirm again until the deposit is ledger_confirmed.
A bearer is a credential: never share it or put it in a URL, file, chat, or command line. When the playground answers 401, the key or session is no longer valid; request a new one.

​
Identity is not account readiness

The human approves every required DFNS User Action with their passkey. A session bearer does not replace that approval. Orders, funding and withdrawals are not part of this guide and require their own authorization and checks. No step here guarantees a successful live flow. Keep credentials and private identifiers in memory, never in command-line arguments, logs, files or chat.

​
Shared reference

Use the REST API reference for request and response contracts. Use WebSockets, not REST polling, for live data; follow the shared channel documentation.