> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trdrs.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Build a front end
> The engine serves data, orders, account state and streams; you supply the screens. What to assemble, and in what order.
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](/chart-integration) 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](/partner-platform/http-clients/typescript).
* **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.
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](/partner-platform/overview/keys) sets out the three permission levels and the routes each
one reaches.
One call tells you the key works and the base URL is right, before any UI exists:
```bash theme={null}
curl "$TRDRS_API_BASE_URL/api/market/time" \
-H "Authorization: Bearer $TRDRS_TENANT_KEY"
```
Then fetch [market-data limits](/api-reference/market-data/get-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](/guides/market-data-overview) is the shelf: symbols, history, quotes, streams.
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](/chart-integration) carries the install, the route-by-route mapping, and the saved-resource
adapter. [Find symbols](/guides/find-symbols) and [Backfill history](/guides/backfill-history)
carry the data rules the chart relies on.
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.
```ts theme={null}
for await (const event of client.marketData.streamLiveBars({ instrument: 'ESU6', tf: '1m' })) {
// a full snapshot arrives first on every (re)connect, then live events
}
```
[Stream live data](/guides/stream-live-data) covers the bar stream, the multiplexed stream a
multi-chart layout wants, and the account stream.
[Streaming](/partner-platform/overview/streaming) states the reconnect contract in full.
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](/guides/place-your-first-order) runs it end to end.
[Protect a position](/guides/protect-a-position) covers moving the levels after entry,
[Idempotency](/partner-platform/overview/idempotency) covers why the retry is safe, and
[Errors](/partner-platform/overview/errors) covers the refusal shapes your screens have to render.
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](/api-reference/account/stream-account-updates) is the route.
[Track fills and P\&L](/guides/track-fills-and-pnl) covers the durable ledgers behind it, and
[Set risk controls](/guides/manage-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](/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](/guides/account-paths) 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.
| Seam | Interface | What you supply |
| --------------- | ---------------------- | ----------------------------------------------------------------------------------- |
| Market data | `ChartDatafeed` | `search`, `resolve`, `history`, `subscribeBars`; optional `serverTime` and `config` |
| Saved resources | `ChartSaveLoadAdapter` | list, read, write and delete for charts, layouts, drawing documents and templates |
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](/guides/publish-a-datafeed) carries the depth.
## Where to go next
Quick Charts over this API: the install, the seams, and the route-by-route datafeed mapping.
Typed methods for every route, streams as async iterators, and named errors.
Every API operation as a command, generated from the served contract when it runs.
Every route with a worked example and ready-to-paste TypeScript and curl.