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

# Get history sync status

> Returns how far trdrs has copied the account's fill history and order history from the provider. Use it to tell "no history yet" from "history still being copied" before you show an empty list as if it were complete.

Required key: Trading API key.



## OpenAPI

````yaml /api/openapi.json get /api/account/sync-status
openapi: 3.1.0
info:
  title: trdrs Engine API
  version: 1.1.0
  description: >-
    ## API Reference


    Every route the trdrs engine serves, with what to send and what comes back.
    It covers market

    data and news, trading and account state for a trader's own software,
    Connect pre-registration,

    the venue routes a prop firm or brokerage runs its accounts through, and the
    Legacy Partner API.


    Start with the Quickstart for your first call. The API standards hold the
    rules every route

    shares: keys, errors, rate limits, idempotency, paging and streaming.
servers:
  - url: https://app.trdrs.co
    description: Production
  - url: /
    description: This engine
security: []
tags:
  - name: Venue platform preview
    description: >-
      Run your venue: its providers, instruments, conditions, groups, routes,
      stages, venue rules, keys, accounts, usage, balance receipts and webhooks.
      These routes are in preview. They are served on the sandbox to every
      venue, and production access is arranged when a venue qualifies. Every
      route here under `/api/partner/` takes a Venue key. The back office
      reaches the same routes under `/api/operator/` with a verified owner’s
      session, because a browser never holds a Venue key, and both run the same
      checks. Changes to these routes are additive only from here on, and the
      Legacy Partner API routes stay as they are.
  - name: Market data
    description: >-
      Search and look up symbols, read price history and quotes, check the
      server clock, and stream live bars. Crypto prices come from each
      provider’s public feed. Futures prices are licensed to each user and
      stream from your own login at a provider that carries them, so without one
      connected, a futures request answers 503 `feed_requires_connection`.
  - name: News
    description: >-
      Market news and the economic calendar, from licensed and open sources,
      tagged with futures roots as they arrive. The content is the same for
      everyone, and these routes admit the same callers as market data: a
      licensed origin, a session or a Trading API key. Page headlines by publish
      time, filter them by instrument root, and stream them live over
      server-sent events. Thumbnails come through the image route.
  - name: Trading
    description: >-
      Place, change and cancel orders, set a position’s exits, and close or
      flatten positions. Every call that places an order takes a `clientOrderId`
      as its idempotency key.
  - name: Account
    description: >-
      Read an account a trader can trade: its balance, positions, working
      orders, fills, profit and loss history, and the live account stream. You
      don’t create accounts here. A trader connects their own account at a
      provider, or opens their own Demo on the paper book, in the trdrs app. A
      venue issues accounts on the paper book with Issue an account into a
      group, and a firm pre-registers accounts at a provider through Connect
      with Pre-register a trader’s account.
  - name: Connect
    description: >-
      Connect is the account picker a trader opens, in the trdrs app or embedded
      on a firm’s site. It lists the built-in providers and every listed venue.
      The pre-registration routes let a firm fill it in ahead of time. You tell
      trdrs that a trader has an account at a built-in provider: their sign-in
      email, and optionally the account number and login name. When that trader
      signs in, Connect shows the account ready to link, and they sign in to the
      provider themselves, once. Nothing here sends a password or grants access
      before the trader’s own login succeeds. You can list who you
      pre-registered and who has linked, and cancel a pre-registration that
      hasn’t been used. A pre-registration expires after 30 days, and sending it
      again refreshes it. These routes take the Partner key. They belong to
      Connect, not to the Legacy Partner API. The whole flow is in the **[Quick
      Start](/docs/guides/quick-start)**.
  - name: Firm accounts (legacy)
    description: >-
      Legacy Partner API. Each route here has a venue twin under
      `/api/partner/venues/{venueId}/accounts…`, which takes a Venue key and a
      named scope, and new integrations use those. This group stays for firms
      that predate venues, and both run the same operation. These routes issue
      and manage evaluation accounts on the paper book with your Partner key:
      the trader trades them on trdrs, and your firm owns their lifecycle. Every
      route sees only the accounts your firm created through this API, so an
      account the same trader opened themselves is invisible here. Creation is
      batched with a result per item, and every write carries your own
      `referenceId`, so a pipeline that crashes can retry safely. These routes
      are served where the engine runs prop evaluations. Elsewhere, every route
      in this group answers `404`.
  - name: Billing
    description: >-
      Legacy Partner API, per firm. What your firm is billed for in a month,
      counted from its fills, and the accounts behind the number. The venue
      routes Read the venue’s metered usage for a month and Read the accounts
      behind the venue’s usage replace these, which still take the Partner key.
  - name: Webhooks
    description: >-
      Legacy Partner API. The venue routes Register a webhook, List the venue’s
      webhooks and Read a webhook’s delivery log replace these, with a Venue
      key, and an endpoint registered either way receives the same events.
      Register an https endpoint, and trdrs pushes events to it, so your back
      office doesn’t have to poll. Every delivery is signed (`trdrs-signature:
      t=<unix>,v1=<hmac-sha256>` over `${t}.${rawBody}`), so you can prove it
      came from trdrs and is fresh. Every delivery is also durable: a failed
      attempt is retried with backoff for about nine hours, and the whole log is
      readable, so an endpoint that was down gets its events late rather than
      never. The pre-registration events (`registration.*`) fire wherever
      Connect runs, and the account events fire where the engine runs prop
      evaluations.
  - name: Challenges
    description: >-
      Legacy Partner API. Stage policies on a venue replace the firm’s half of
      this, and the trader’s enrollment flow has not moved yet. These routes
      list evaluation programs and a trader’s own enrollments. **Preview: the
      one group in this reference outside the additive-only guarantee.** Their
      shapes will change when challenges are rebuilt; see Stability. **They take
      a signed-in session, not a key**, and are served only where the engine
      runs with `CHALLENGES_ENABLED`. Without it, the routes don’t exist and
      every one answers `404`. The administration half isn’t documented here,
      because it is trdrs’s own tooling, not part of the API.
paths:
  /api/account/sync-status:
    get:
      tags:
        - Account
      summary: Get history sync status
      description: >-
        Returns how far trdrs has copied the account's fill history and order
        history from the provider. Use it to tell "no history yet" from "history
        still being copied" before you show an empty list as if it were
        complete.


        Required key: Trading API key.
      parameters:
        - name: broker
          in: query
          schema:
            type: string
          description: >-
            The provider the account is at, such as `rithmic` or `paper`. Omit
            it to use your default provider. An unknown value is refused with
            400, never replaced with another provider.
        - name: account
          in: query
          schema:
            type: string
          description: >-
            The account number at that provider. It must be one of your own
            accounts, or the call is refused with 400.
      responses:
        '200':
          description: The state of each history. Each is null until copying has started.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/SyncStatusResponse'
        '400':
          description: No provider is connected.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
        '401':
          description: The key is missing, unknown or revoked.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
      security:
        - tenantKey: []
      x-codeSamples:
        - lang: javascript
          label: TypeScript
          source: >-
            const res = await
            fetch('https://app.trdrs.co/api/account/sync-status', {
              headers: { Authorization: `Bearer ${process.env.TRDRS_API_KEY}` },
            })

            const data = await res.json()
        - lang: shell
          label: cURL
          source: |-
            curl 'https://app.trdrs.co/api/account/sync-status' \
              -H "Authorization: Bearer $TRDRS_API_KEY"
components:
  schemas:
    SyncStatusResponse:
      type: object
      description: How far trdrs has copied the account's fill and order history.
      properties:
        fills:
          $ref: '#/components/schemas/SyncStream'
          description: The fill history.
        orders:
          $ref: '#/components/schemas/SyncStream'
          description: The order history.
      required:
        - fills
        - orders
      example:
        fills:
          backfillDone: true
          hasError: false
          lastError: null
          updatedAt: '2026-08-24T14:32:00Z'
        orders:
          backfillDone: true
          hasError: false
          lastError: null
          updatedAt: '2026-08-24T14:32:00Z'
    ErrorResponse:
      type: object
      description: >-
        The body of every error response. It always carries `error`, an English
        sentence you can show. A refused trading request also carries `code`,
        one of the refusal codes, and `params`, the details of that refusal.
        Translate by `code` and `params`, and show a generic message for a code
        you don't recognize. Other errors may carry a `code` of their own.
      properties:
        error:
          type: string
          description: What went wrong, as an English sentence.
        code:
          type: string
          description: >-
            A stable machine code. On a refused trading request, it is one of
            the refusal codes.
        params:
          type: object
          description: >-
            The details of the refusal named by `code`, on a refused trading
            request.
      required:
        - error
      example:
        error: invalid_instrument
    SyncStream:
      type:
        - object
        - 'null'
      description: >-
        How far trdrs has copied one history from the provider, or null before
        it starts.
      properties:
        backfillDone:
          type: boolean
          description: True once the past history has been copied.
        hasError:
          type: boolean
          description: True when the last copy attempt failed.
        lastError:
          type:
            - string
            - 'null'
          description: Why it failed, or null.
        updatedAt:
          type: string
          format: date-time
          description: When the state last changed.
      required:
        - backfillDone
        - hasError
        - lastError
        - updatedAt
  securitySchemes:
    tenantKey:
      type: http
      scheme: bearer
      description: >-
        The Trading API key (`trdrs_sk_…`), for market data, orders and account
        state on the accounts its owner holds. Use it server-to-server only,
        never in a browser. Its scope is named `tenant` in the API.

````