> ## 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.

# Quick Start

> This is the shortest path to a working trdrs integration.

Start with the [developer sandbox](/sandbox) to prove sign-in and key access with one catalog
request. Its preview currently supports reference data only.

[Open the sandbox and create a key](https://sandbox.trdrs.co/developer).

The six steps below apply to a production integration with the required production credentials;
its trading and provisioning endpoints are not part of the sandbox onboarding preview.

<Note>
  **Check which path you are on before step 5.** A firm gets a trader trading one of two ways.
  Either trdrs creates the account — `POST /api/partner/accounts`, no venue, no credential, nothing
  to email — or you register an account that already exists at your own venue, which is what step 5
  does. [Two ways in](/guides/account-paths) sets them side by side. If the accounts come from us,
  that page is your path and step 5 is not.
</Note>

## Agent prompt

Building with a coding agent? Set the values below, paste this in, and the agent has everything
it needs:

```text theme={null}
Integrate the trdrs Partner API into this app.

Use these environment variables:
- TRDRS_API_BASE_URL
- TRDRS_TENANT_KEY
- TRDRS_PARTNER_KEY, only for Connect registration operations

First call GET /api/market/config and GET /api/market/time.
Then wire symbol search, symbol info, history, quotes, and the market stream.
Use clientOrderId for every order intent.
Treat 429 Retry-After, 423 risk_locked, and stream reconnect snapshots exactly as documented.
Never put a trdrs_sk_ key in browser code.
```

<Steps>
  <Step title="Get a key">
    Ask trdrs for the key type that matches your job.

    A tenant key is for your trading product: market data, trading, and account state.

    ```env theme={null}
    TRDRS_API_BASE_URL=https://app.trdrs.co
    TRDRS_TENANT_KEY=trdrs_sk_replace_me
    ```

    A partner key is for provisioning only, under `/api/partner/`.

    ```env theme={null}
    TRDRS_PARTNER_KEY=trdrs_sk_replace_me
    ```

    Both stay on your servers. See Keys for the full permission model.
  </Step>

  <Step title="Check the engine">
    Two calls prove your key works and tell you what this engine serves:

    ```bash theme={null}
    curl "$TRDRS_API_BASE_URL/api/market/time" \
      -H "Authorization: Bearer $TRDRS_TENANT_KEY"
    ```

    ```bash theme={null}
    curl "$TRDRS_API_BASE_URL/api/market/config" \
      -H "Authorization: Bearer $TRDRS_TENANT_KEY"
    ```

    `/api/market/config` is worth fetching once at startup and keeping. It declares the timeframe
    grammar, the request limits, and the asset classes this engine can answer for, straight from the
    same constants the routes enforce. Validate against it and your app reaches the same verdict the
    engine will.
  </Step>

  <Step title="Chart data">
    Search for an instrument, then pull history. History takes an `instrument`, a `tf` timeframe
    token, and `countBack` for how many bars you want:

    ```ts theme={null}
    const baseUrl = process.env.TRDRS_API_BASE_URL!
    const tenantKey = process.env.TRDRS_TENANT_KEY!

    async function trdrsGet<T>(path: string): Promise<T> {
      const res = await fetch(`${baseUrl}${path}`, {
        headers: { Authorization: `Bearer ${tenantKey}` },
      })

      if (!res.ok) {
        const body = await res.json().catch(() => ({}))
        throw new Error(`${res.status} ${body.error ?? res.statusText}`)
      }

      return res.json() as Promise<T>
    }

    const symbols = await trdrsGet('/api/market/symbols?q=ES&limit=10')
    const history = await trdrsGet('/api/market/history?instrument=ESU6&tf=1m&countBack=500')
    ```

    For live bars, open `/api/market/stream` with the same instrument and timeframe. It sends a full
    snapshot on connect, then live bars. See Streaming for the one rule that makes reconnects free.
  </Step>

  <Step title="Wire orders carefully">
    Every order intent needs one stable `clientOrderId`. Mint it when the trader commits, and reuse
    the same value on every retry of that intent. This is what makes a timeout harmless: retry with
    the same id and you either place now or learn it already placed.

    ```ts theme={null}
    const clientOrderId = crypto.randomUUID()

    const res = await fetch(`${baseUrl}/api/trading/order`, {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${tenantKey}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        instrument: 'ESU6',
        side: 'buy',
        qty: 1,
        orderType: 'market',
        clientOrderId,
      }),
    })
    ```

    Orders route to your priority default account. To target a specific one, add `broker` and
    `account` as query parameters: `/api/trading/order?broker=tradovate&account=DEMO123`.
  </Step>

  <Step title="Connect registrations">
    If you are a broker or prop firm with existing venue accounts to hand off, register them with a
    partner key. A registration pre-fills the trader's connect flow but never sends a password:

    ```bash theme={null}
    curl "$TRDRS_API_BASE_URL/api/partner/connect/accounts" \
      -X POST \
      -H "Authorization: Bearer $TRDRS_PARTNER_KEY" \
      -H "Content-Type: application/json" \
      -d '{
        "email": "trader@example.com",
        "accountNumber": "PA-4821-07",
        "venueLogin": "jsmith-apex"
      }'
    ```

    Your firm notifies the trader and delivers the venue credential directly. trdrs sends no customer
    handoff email, and the registration API rejects the retired `handover` field.

    Skip this step if the accounts come from us instead: `POST /api/partner/accounts` creates
    evaluation accounts on the trdrs venue for a trader's sign-in email, with no venue, no credential
    and no connect screen. Both paths run from your own back office at any scale, and
    [Two ways in](/guides/account-paths) is the page that picks between them.
  </Step>

  <Step title="Pass conformance">
    Before going live, prove:

    * keys are server-side only;
    * every order retry preserves `clientOrderId`;
    * `429` respects `Retry-After`;
    * streams reconnect and accept full snapshots;
    * null money fields stay unknown, not zero;
    * Connect registrations never include credentials.

    See API Reference for the exact request and response models, each with a worked example and
    ready-to-paste TypeScript and curl.
  </Step>
</Steps>