Skip to main content
Run your trading screens on your traders’ own accounts. Once a trader has connected an account or opened your white-label paper, your backend reads their accounts, positions, orders and market data, and routes the orders they place in your interface, much as the trdrs trading app does. Every order is the trader’s own: they place it on your screen, on their own account, and your backend carries it to trdrs and shows them what comes back. Use this page when you build the screens behind your Connect, after the Connect quickstart. By the end your backend lists a trader’s accounts, checks and routes their order, moves and cancels it, follows the account on its live stream, and you know how to stop all of it for one trader.

​
Before you start

  1. Your app’s API key. The Connect quickstart creates one.
  2. A trader who connected through your Connect, such as trader-test-1 from the quickstart, with the Demo they opened.
  3. TRDRS_API_BASE_URL and TRDRS_API_KEY in your shell, and the trader’s account in PROVIDER and ACCOUNT, as the quickstart sets them.

​
Name the trader on every request

Every request for a trader carries your API key and your own id for the trader:
The request runs as that trader, on their own accounts only: the accounts they connected through your Connect and the Demo they opened from your white-label paper. The id is the one your Connect links name. Trading never creates a trader: an id becomes one of your traders the first time a Connect link names it, and until then every request for it answers 404 trader_not_found. Your app’s API key reaches every one of these routes for your traders. A venue’s backend calls the same routes for its own traders with its Venue key, which reaches what its scopes say:
Your API key routes orders on the accounts of every one of your traders. Keep it on your server, never in a browser or a mobile app. A request that carries a cookie or a browser Origin beside it is refused, so your server is the one place that calls these routes.
1

List the trader's accounts

Read every account the trader holds through your Connect.
The response’s accounts lists each one with its provider and accountNumber, which name the account on every other route, its balance, openPositions and capabilities, and its accountId, the id a connected Connect link names in result. Only this trader’s accounts appear.
2

Read one account

Read the account as one moment: its balance, open positions, working orders and exits, which always agree with each other.
GET /api/account/instruments lists the symbols the account trades, for your symbol picker, and the other account routes read positions, orders, fills and history the same way, with the account named in the query.
3

Check what the account may do

When the trader picks an instrument, ask what the account may do on it before they order. It runs the checks an order runs, in the same order, without sending anything, and on the paper book it readies the instrument’s prices for the order that follows.
actions holds one verdict for each action: open, reduce, close, protect, flatten and cancel. A blocked action carries the refusal the order would get, with its code and message, so your ticket can say why before the trader presses anything.
4

Route the trader's order

When the trader places an order on your screen, send it on to their account. trdrs prices, checks, places and records it as it does an order from the trdrs trading app. This one is a limit order below the market, so it rests:
The example assumes the market near 100,000, so a buy at 90,000 rests. The response names the order with its providerOrderId and a filledQty of 0. Keep the id: it’s how you move or cancel the order.Mint clientOrderId once, when the trader presses the button, and send the same id on every retry: a second request with it answers 409 and never places a second order. trdrs records every order request with the key that sent it and the trader whose order it is. Place your first order covers order types, exits and every refusal.
5

Move or cancel it

Move the working order to a new price, under a new clientOrderId of its own:
Show the trader the outcome: amended and replaced mean the order moved, and the order working afterwards is the providerOrderId in the response. Then cancel it by that id:
A 200 means the provider accepted the cancel. The account stream, next, tells you what is still working.
6

Follow the account on its stream

Don’t poll. Open the account stream for the trader: it sends the whole account first, then every change, and one stream drives your position panel, your order list and your lock banner together.
Each account event is the whole account at one revision: replace what you hold with it, and ignore an event at or below the revision you have. A lock event says when a risk control has locked the account. The stream proves your key and the trader again on every heartbeat, every 15 seconds, so a revoked or expired key, or a suspended trader, ends it at the next one. On a reconnect, replace your state with the fresh snapshot. Streaming describes the events.

​
Forward your page’s requests

Your trading screens run in a browser, which never holds your API key, so your server stands between them and trdrs. A thin forwarder is enough: your page calls a path on your own server, and your server sends the same request to trdrs’s route with your key and the trader’s id, then passes the answer back. Your screens can then use trdrs’s request and response shapes as they are.
  • Forward only the trader routes: /api/account/…, /api/market/…, /api/instruments, /api/news, /api/calendar, /api/risk, /api/trading/… and /api/exit-plans. Nothing else.
  • Name the trader from your own session. Add x-trdrs-trader from the trader your own sign-in verified, never from anything the browser sent.
  • Refuse requests from other sites. Your session cookie rides every request to your server, so answer a cross-site request with nothing, and forward a request that changes anything only when its Origin is your own site.
  • Send trdrs only what it reads: the method, the path, the query, the JSON body, and the Accept, Content-Type, Idempotency-Key and Last-Event-ID headers. Pass back the status, the body and Retry-After, never a cookie.
  • Pass a stream through as it arrives, and end it when the browser leaves.

​
Prices for futures

Futures prices are licensed to each user, so a trader’s futures prices come from a login they connect through your Connect at a provider that carries them, today Rithmic on their firm’s production system. Without one, the trader’s Demo lists no futures, and a futures order answers 422 market_data_unavailable with cause login_missing. A Rithmic Test login carries no market data, so futures can’t be traded in the sandbox: build and test with crypto, such as HYPERLIQUID:BTC, whose prices come from public feeds and need no login. Providers says where each provider’s prices come from.

​
Suspend a trader

Suspend a trader to stop every request for them at once, for example while you review their account. Every request for them is then refused with 403 trader_suspended, their open streams close within a heartbeat, and they can’t open your white-label paper. Suspending closes no position and cancels no order. An owner or an editor of your app suspends a trader in the Connect dashboard’s Traders, by your own id for them, and lifts the suspension there. A venue suspends one of its own traders with PUT /api/venues/{venueId}/traders/{trader}/suspension and a Venue key carrying venue:configure, and lifts it with DELETE on the same path.

​
Handle refusals

These come before any route reads the request: Past these, each route answers as it does for any account: an order can still be refused, for example 423 risk_locked when a risk control has locked the account. Place your first order lists the order refusals. Market data requests that name a trader are limited per key and trader rather than per your server’s address, so one busy trader never spends another’s allowance. Rate limits gives the numbers.

​
Test it end to end

  1. List trader-test-1’s accounts. You see their Demo.
  2. Place the limit order above. It rests, and the account stream shows it among the working orders.
  3. Move it, then cancel it. The stream shows it at the new price, then gone.
  4. Send the order request again with the same clientOrderId. You get 409, and nothing new is placed.
  5. Add -H "Cookie: a=b" to any request. You get 400 credential_not_allowed.
  6. List the accounts of an id no Connect link named. You get 404 trader_not_found.

​
The routes this page calls

The account, market and trading routes are the ones the trdrs trading app uses. Each takes your app’s API key, which starts trdrs_ck_sandbox_ in the sandbox, with the trader it acts for: If you run a venue and issue accounts to your own traders by your own id, your Venue key reaches those accounts on the same routes. Venue accounts shows how to issue one.

​
Next steps

Build a front end

Draw your traders’ charts, tickets and positions over these routes.

Place your first order

Learn every order type, exit and refusal the trading routes give.

Tiles and white-label paper

Choose your tiles, and reset or retire a trader’s Demo.

Pass conformance

Prove your backend handles the journey and its faults.