Skip to main content
trdrs is one API for running a trading product. Market data, order entry, protective exits, account state, and provisioning all live behind a single base URL, with the same request shapes across every venue we connect to. You write your integration once. When your traders move from futures to crypto, or from one broker to another, your code does not change. The API is deliberately small and deliberately boring. Plain HTTPS and JSON. Two live streams over Server-Sent Events, so a curl command is a working client. Every request that can create or move money takes an idempotency key, so a retry is always safe. Every sample in this reference runs against the production host as written. It is also built to be read by machines. The full contract is served as OpenAPI at /docs/openapi.json, every operation carries a worked example with real values, and the HTTP clients tab includes prompts you can paste straight into a coding agent. An agent given this documentation and a key can build a working integration without a human reading a single page. Humans are welcome too.

​
What is served

  • market data: symbol search, resolution, history, quotes, a live bar stream, and the futures contract catalog;
  • news: aggregated market headlines, with a live stream and an image proxy;
  • calendar: the economic calendar, with its own live stream;
  • trading: orders, brackets, replaces, cancels, protective exits, position actions;
  • account: balances, positions, orders, executions, a live account stream, and the risk controls that gate every order;
  • Connect: account registration handoff for brokers and prop firms;
  • Challenges: the prop evaluation surface, served as a PREVIEW.
Everything in API Reference is a real served route. Guide material lives in these pages, and the machine-readable contract lives in API Reference. The two are held together by the build: a test suite parses the engine’s own router and fails if any key-reachable route is missing from the reference, and every documented schema is locked to the wire types the engine compiles against. A route cannot ship undocumented, and a documented shape cannot drift from what the engine answers. Three principals reach one engine: a trading front end with a firm key, a firm back office with a partner key, and a signed-in trader with a session cookie. Three kinds of caller reach the engine, and each carries a different credential. Your trading front end calls with a firm key from your server. Your back office issues accounts with a partner key. A trader signed in to a first-party app carries a session cookie. The scopes do not overlap, so a leaked credential in one lane never opens another. Keys and permissions explains each level in detail.