Skip to main content
The engine serves the market data, the order path, the account state and the live streams. A front end supplies the screens over them, and nothing else — there is no trading logic to reimplement behind your UI, because the parts that can create or move money live on this side of the wire. Three pieces are already built, so write none of them:
  • Quick Charts — the chart library the trdrs platform itself runs: candles, drawings, indicators, multi-chart layouts, bar replay and saved resources. It is open source and consumes interfaces rather than a backend, so it renders your data. Charting covers feeding it from this API.
  • @trdrs/sdk — the TypeScript client for every route, generated from the same contract this site renders. Typed methods, streams as async iterators, and refusals named as error classes so a 423 cannot be mistaken for a failure. See the TypeScript SDK.
  • The OpenAPI document — if you write in another language, point your own generator at the served document rather than hand-writing a client. Every route, model and example comes off it.

The order to build in

Each step depends on the one above it. Skip ahead and you debug two unknowns at once.
1

Get a key

Ask trdrs for a tenant key: it reaches market data, trading and account state, which is the whole of what a front end needs. A partner key is a different credential for provisioning under /api/partner/, and most front ends never hold one.Both keys stay on your servers. A chart on your own domain reads the market-data routes directly once your origin is allowlisted at onboarding — that allowlist is what makes a browser request work, not a key in browser code.Keys sets out the three permission levels and the routes each one reaches.
2

Prove a read

One call tells you the key works and the base URL is right, before any UI exists:
Then fetch market-data limits once at startup and keep them. They declare the timeframe grammar and the request caps the routes enforce, so your app can reach the same verdict the engine will. Market Data is the shelf: symbols, history, quotes, streams.
3

Render a chart against the datafeed seam

Quick Charts takes a ChartDatafeed and draws everything above it. Its four required methods — search, resolve, history, subscribeBars — map onto the engine’s market-data routes nearly one to one, which is why the wiring is short and why the same chart works against a feed of your own.Charting carries the install, the route-by-route mapping, and the saved-resource adapter. Find symbols and Backfill history carry the data rules the chart relies on.
4

Subscribe to a stream

Both live streams speak Server-Sent Events, and both follow one rule: on every connect and reconnect the stream replays a full snapshot, then applies live events. A dropped connection therefore needs no client bookkeeping — you re-render from the snapshot and carry on.
Stream live data covers the bar stream, the multiplexed stream a multi-chart layout wants, and the account stream. Streaming states the reconnect contract in full.
5

Place an order with exits

Every order intent carries a clientOrderId you mint when the trader commits and reuse on every retry, so a timeout is harmless. Attach stopLoss and takeProfit to the order itself: they are placed with it as one unit or not at all, which is the behaviour a ticket should offer by default. Read the risk state first — a locked account answers 423 to every order, and that is a state to display, not an error to retry.Place an order runs it end to end. Protect a position covers moving the levels after entry, Idempotency covers why the retry is safe, and Errors covers the refusal shapes your screens have to render.
6

Follow account state on the account stream

Do not poll for what the account now holds. The account stream applies the same snapshot-then-events contract to positions, working orders, the summary and the risk lock, so one subscription drives the position panel, the order book and the lock banner together.Stream account updates is the route. Track fills and P&L covers the durable ledgers behind it, and Set risk controls covers the controls that produce the lock.

What you should not build

A front end is a choice, not a requirement. Your traders already have a finished workspace: charts, alerts, the order ticket, bar replay, journaling, the copier and the rest, hosted and maintained by us. What your traders get is the inventory. An evaluation you sell on Monday is tradable that day on a platform you did not write. Account connection is a solved surface too. A trader either receives an account we created on the trdrs venue, or finishes a pre-filled connect screen for an account that already exists at yours — both handled by the platform, and neither one a screen you should rebuild. Two ways in sets them side by side. Most firms ship faster by putting their traders on the trdrs platform and building only the screens their own business genuinely needs: an internal risk desk, a payout console, a branded landing surface. Build those, and let the platform carry the trading.

Where the seams are

Quick Charts takes two host-supplied adapters and nothing else. Everything the chart owns — drawings, indicators, panes, scale modes, the legend, replay — needs no adapter at all. Trading is deliberately not one of them. The chart carries no orders, accounts or executions; an application that trades composes those beside the chart through the extension seam (ChartExtension), which draws on the chart, contributes menu rows and commands, keeps its state in the chart’s own save blob, and is taken down completely at teardown. That is why the order path in the walkthrough above is your own code against the trading routes rather than a chart setting. The datafeed seam points both ways. createUdfDatafeed is the on-ramp that lets Quick Charts read a UDF-style feed, and that same UDF contract is the one a firm publishes to us when its market comes from a venue the engine does not connect to — three read-only JSON endpoints, and a server that already drives the chart drives the engine unchanged. Publish a datafeed carries the depth.

Where to go next

Charting

Quick Charts over this API: the install, the seams, and the route-by-route datafeed mapping.

TypeScript SDK

Typed methods for every route, streams as async iterators, and named errors.

CLI

Every API operation as a command, generated from the served contract when it runs.

API Reference

Every route with a worked example and ready-to-paste TypeScript and curl.