Create, authorize, execute
Orders, cancellations, setup, and withdrawals all run the same pipeline.Create
You send the venue, the account, the action type, and its parameters. The backend returns an array of steps. One call can return more than one: raising leverage before an order arrives as two steps, in order.
Authorize
Each step carries exactly one authorization payload, selected by the step’s signing method. Either the user’s wallet signs it or the SDK signs it with the credential it holds for that account.
Execute
Signed steps go back and the response returns one result per step. Success carries the venue’s identifiers; failure carries an error and often a structured code.
That last one is the exception to the pattern. A session step never goes to execute, because the plugin completes it directly.
Who signs
Every action declares who authorizes it, and there are two answers. The user authorizes anything that grants a capability or moves money out: approving the agent, depositing, signing in, and withdrawals on some venues. These invoke the wallet. The SDK authorizes trading, using the credential it owns for that account on that venue. This is why order flow has no wallet popup. The credential was granted once, during setup, by a user action that did. Some actions list both, because the protocol needs a contribution from each. The high-level trading methods handle the SDK-signed half without being asked, and setup is coordinated end to end by a single call rather than by you scripting each venue’s scheme.Where credentials live
Each venue’s plugin persists its own trading credentials through a storage adapter, and the adapter is replaceable. The default targets the browser. Values are encrypted before they are written to local storage, and the key that encrypts them is held as a non-extractable handle in the browser’s own key store rather than as a value the page can read back. An environment missing either of those primitives falls back to a session that does not persist, rather than writing the credential out in the clear.Pass your own adapter to a provider’s store to keep credentials somewhere else. That is the supported path for server-side or native integrations, where the browser default does not apply.
Streaming
Market and account updates arrive over WebSocket connections made to the venue itself rather than proxied. You register a streaming provider per venue, and subscribing returns the function that tears the subscription down. Multiple listeners on one channel share a single wire subscription, so components can subscribe independently without opening a connection each. Each venue has its own native protocol and its own rate limits underneath, which the plugin maps onto the common channel names.Failure
Results come back one per step, which means a multi-step action can partially succeed. An order preceded by a leverage change can leave the leverage applied and the order rejected, and treating the whole call as failed would misreport that. Structured error codes are the thing to branch on. A plugin can also react to results before a failure reaches you, which is how a credential the venue has stopped accepting gets evicted locally instead of failing every subsequent order the same way.Next steps
Venues
How each venue implements setup, signing, and withdrawals.
Quickstart
The pipeline above, as running code.
Error codes
The full code list and what each one means.
Method reference
Parameters and return shapes for every method.