Skip to main content
WebSocket is the primary way to trade on Arcus: one connection multiplexes order routing and every data channel, and each request is signed on its own. This quickstart gets you from nothing to a live order on testnet in three steps.
New here? The REST track is a gentler start. Requests target testnet (https://api.testnet.arcus.xyz); new accounts start empty — fund yours with the Testnet Deposit button (~$1,000), or an on-chain deposit for more. See Authentication for signing.

Step 1: Install

Only published libraries — no Arcus package required.

Step 2: Get an API key

Your API key is an Ed25519 keypair; the server stores only the public half, and the key is registered to your wallet by a one-time REST call authenticated by an EIP-712 typed-data signature (eth_signTypedData_v4) — createApiKey is REST-only, so even socket-first clients register once over REST (the legacy EIP-191 scheme is deprecated but still accepted during the migration window). The Arcus web app does all of this for you and is the quickest way to get a key; you can also do it entirely in code.
  1. Open the API Keys page — testnet, or mainnet for production — and connect the wallet you’ll trade from.
  2. Enter a name and click Generate. The app creates the keypair in your browser.
  3. Copy the API Signing Key now — it’s the private half, shown once, and cannot be recovered. Pick a Subaccount # (default 0) and Days Valid (up to 180), then click Authorize and confirm the signature in your wallet.
That registers the key — nothing to run. Load the signing key you copied and skip to Step 3:
The steps below read the master address as wallet.address; with a web-app key, use your wallet_address wherever you see it.

Option B — Generate in code

Generate a fresh keypair and register it with one createApiKey call — the same operation the web app performs:

Step 3: Place an order

Open the socket, then send signed requests correlated to their responses by id. Trading methods sign the same typed canonical payload as REST: the compact JSON object is the signing message, and its ct field must equal the envelope timestamp (Unix nanoseconds). Price and size are signed as integer ticks/quantums — convert them with the market’s tickSize / stepSize. See Authentication for the field reference.
A successful order returns a 202 acknowledgement; the order’s lifecycle (fills, cancels) plays out on the orders and userFills channels. placeOrder, cancelOrder, and modifyOrder use the typed payload above; cancelAllOrders and setLeverage use the legacy timestamp + action + canonicalJSON(payload) message. A batch signs each order individually with its own typed payload under one shared timestamp, each embedding its own signature — see the REST batch example for the exact headers.
In the request body, quantity and price stay decimal strings. The integer p/q in the signed payload are derived from them via tickSize / stepSize; the two must agree.

Next: stream your fills

Coming soon. The userFills and orders channels stream your fills and order updates in real time (subscribe by account address). A copy-paste example will be added here.