Start from what’s built
Two pieces already exist, so you don’t write them:- Quick Charts is the chart library the trdrs trading platform runs: candles, drawings, indicators, layouts with several charts, bar replay and saved charts. It’s open source and draws whatever data you give it. Charting shows how to feed it from this API.
- The OpenAPI document describes every route and model. Point your own client generator at it rather than writing a client by hand.
Keep keys on your server
Your front end talks to your own backend, and your backend calls trdrs with the key. Browser and mobile code never holds a key, because anyone can read what a page ships. For screens on your own accounts, create a Trading API key in API access in the sandbox. It reaches market data, trading and account state, which is everything a trading screen needs. Keys sets out each key and what it reaches. If the screens are for your own traders, who sign in only to your app, your backend uses your Connect app’s API key instead, names the trader on each request, and routes the orders they place. Connect shows how your traders connect their accounts, and Route your traders’ orders how your backend reads their accounts and routes their orders. A venue’s screens for its own traders work the same way, with its Venue key carryingtrader:read or trader:trade. The steps below are the same in every case.
Build it in this order
Each step depends on the one before it, so build and test them in order. Skipping ahead means debugging two unknowns at once.1
Prove a read
Make one call from your backend before any screen exists. It proves the key and the base URL
are right.A
200 with an instruments array means you’re connected. With a Connect app’s API key or a
Venue key, add x-trdrs-trader with one of your traders’ ids. Then read market-data
limits once when your backend starts, and
keep it: it lists the timeframes and request sizes the engine accepts, so your screens can
check input before sending it.2
Draw a chart
Quick Charts takes a
ChartDatafeed and draws everything else. Its four required methods,
search, resolve, history and subscribeBars, map almost one to one onto the market data
routes, so the wiring is short. Implement them in your backend, or in a front-end module that
calls your backend.Charting has the install and the method-by-route mapping.
Find symbols and Backfill history cover the
data rules the chart relies on.3
Keep it live
Both live streams start with the whole current picture on every connect and reconnect, then
send changes. A dropped connection needs no bookkeeping: you redraw from the first event and
carry on.Cached history arrives first; live bars continue while history loads, followed by a repaired snapshot.Stream live data covers the bar stream, one connection for many
charts, and the account stream.
4
Place orders with brackets
Give every order a
clientOrderId when the trader presses the button, and reuse it on every
retry, so a timeout never places a second order. Send the ticket’s take profits and stop losses as
the order’s exits: trdrs records them as its bracket before it sends the entry, which is what a
ticket should offer by default. Read what the account
may do first, and show a locked account’s
423 as a banner, not as an error to retry.Place your first order runs it end to end.
Protect a position covers moving the levels, and
Errors lists the refusals your screens have to show.5
Follow the account on its stream
Don’t poll for what the account holds. One account stream drives the position panel, the order
list and the lock banner together, each frame at one moment.Stream account updates is the route.
Track fills and P&L covers the history behind it.
Decide what not to build
If you run a venue that issues accounts to traders by their trdrs sign-in email, a front end is a choice. Those traders already have a finished trading platform, hosted and kept up by trdrs: charts, alerts, the order ticket, bar replay, a journal, copy trading and more. What your traders get lists it. An evaluation you sell is tradable at once, on screens you didn’t write. Signing in and connecting accounts are handled too. Such a trader signs in to trdrs and finds the accounts your venue issued in their list, and a provider that needs its own login asks for it once, in Connect. Neither is a screen to rebuild. Core concepts shows the whole structure. A venue’s own traders, named by the venue’s own id for them, sign in to the venue instead, so the venue builds their screens over these routes. On your own Connect app, hosted Connect is the account screen: your page opens it, and you never build a provider’s sign-in. Most venues ship faster by putting their traders on the trdrs trading platform and building only what their own business needs, such as an internal risk desk, a payout tool or a branded landing page.Where Quick Charts meets your app
Quick Charts takes two interfaces from your app and needs nothing else. Drawings, indicators, panes, scales, the legend and replay all live inside the chart.
The chart draws market data. An app that trades adds orders, accounts and fills beside the chart
through
ChartExtension, which draws on the chart, adds menu items and commands, keeps its state
in the chart’s own saved layout, and is removed completely when the chart closes. That’s why the
order path above is your own code against the trading routes.
Next steps
Charting
Install Quick Charts and feed it from the market data routes.
Route your traders' orders
Read your traders’ accounts and route their orders, on your own Connect app.
Place your first order
Send an order with a bracket from your backend, then confirm and close it.
Stream live data
Keep charts and the account live over one connection each.