Authenticated endpoints take a Bearer JWT in the Authorization header:
Obtain one from POST /partner/customers (register) or POST /partner/customers/login — both return it as token, alongside a refreshToken. Refresh with POST /partner/customers/refresh-token before token expires — see Token lifetime below. Tokens are issued per end user, so each of your users trades under their own account, balance and positions. The same token authenticates the WebSocket connection — pass it as auth.token on the Socket.IO client.

​
Token lifetime

  • Access token (token) — expires after 2 hours. Use it as Authorization: Bearer <token> on user-facing endpoints.
  • Refresh token (refreshToken) — valid for 48 hours. Exchange it for a fresh token/refreshToken pair via POST /partner/customers/refresh-token before it expires; after 48 hours the customer must log in again.

​
Base URL

Every REST endpoint is served under the /api prefix.
The real-time endpoint is a separate Socket.IO server, not served from the REST host above. See WebSocket Connection for the Socket.IO host, path, and connection details per environment.

​
Public endpoints

Event discovery, categories, subcategories and market data need no token — you can render markets before a user has signed in. Everything that touches an account (orders, positions, portfolio, wallet) requires one. Integration partners still send their X-API-Key on these calls; see ISV partner authentication below.
Money-movement and trading endpoints additionally require the account to be KYC-verified. A token alone is not sufficient for deposits, withdrawals, or order placement on a non-verified account.

​
ISV partner authentication

Integration partners (ISVs) who onboard their own users onto Dime Trades are issued a server-to-server credential pair. The key half goes on every request to this API:
The secret half is added on every /partner/* endpoint — register, login, refresh-token, logout, kyc, wallet-instructions and the replay endpoints. These are the server-to-server calls that create accounts, mint user tokens and reconcile your wallet instructions. Requests to them without both halves are rejected with 401:
Call POST /partner/customers once per user to create and link their account, then POST /partner/customers/login whenever you need a fresh token for them (or POST /partner/customers/refresh-token to rotate an existing refreshToken instead of logging in again — see Token lifetime). Everything after that — orders, positions, wallet — is the normal user API, called with X-API-Key and Authorization: Bearer <token>.
Keep the key and secret on your backend; they authenticate your platform, not an end user. Anyone holding the pair can mint a token for any of your users.

​
WebSocket authentication

The socket connects with or without a token — authentication is checked per-channel, not at connect time. An unauthenticated socket works for every public channel, but subscribing to an authenticated one is rejected:
There is no separate connect failure to catch. See WebSocket Connection for the full behaviour.