Skip to main content
Sandbox rollout: use https://sandbox.trdrs.co for this workflow. Production availability depends on the production engine release. Use your server-side partner key. These endpoints reach only paper accounts your firm issued through the account-creation API. A trader session, tenant key, or another firm’s key cannot read those accounts. A missing account and an account owned by another firm both return 404. Read access does not require a payment in sandbox. No payment processing belongs in this workflow.

​
Read performance

The response is one consistent database snapshot, identified by asOf, snapshotId and cycle.id. Reads do not create orders, move balances, reset accounts or advance stages. Amounts use the account’s currency, quantities may be fractional, and timestamps are UTC ISO 8601. Example: 3,010ofrealizedprofit,3,010 of realized profit, 10 of fees and a 500promotionalcreditproduce‘netTrading:3000‘and‘balanceAdjustments:500‘.Thecreditcannotsatisfya500 promotional credit produce `netTrading: 3000` and `balanceAdjustments: 500`. The credit cannot satisfy a 3,500 trading target. Closed-trade net profit may differ from account net trading profit while positions are open because entry fees on those open positions have already been charged to the account.

​
Trading days and session rules

A qualifying day is a distinct session containing at least one executed fill. Opening fills, closing fills, and losing trades count. Placing or cancelling an unfilled order, signing in, receiving a credit, or merely holding overnight does not count. Weekends are not excluded: a crypto fill on Saturday counts if it belongs to a distinct session. Defaults are timeZone=America/Chicago and rolloverHour=17. At 17:00 local time the next session starts; its label is the next calendar date. The timezone observes daylight-saving changes. For UTC calendar days, explicitly send timeZone=UTC&rolloverHour=0. Save these rules with your challenge stage and send the same rules on every check. They control analytics grouping; they do not change the engine’s existing risk-monitor session boundaries. Minimum profitable days, minimum volume per day and exchange-holiday exclusions are not evaluated. If your challenge requires them, your backend must also check those rules before advancing.

​
Equity history and completeness

equityHistory.points contains the latest up to 1,000 forward samples, newest first, with at most one sample per minute. The existing P&L worker samples registered paper accounts that have traded, including after a restart. This is a sampled curve, not tick-by-tick history or proof of the exact intraday high/low. It starts after this feature is deployed; earlier equity is not reconstructed. Gaps can occur while the worker is offline. continuous is always false; mayHaveOlderSamples indicates that another page is available. Request the same analytics URL with equityBefore set to equityHistory.nextBefore to retrieve the next older page. Continue until nextBefore is null; verify cycle.id has not changed on each page and restart if it has. Other analytics fields describe the latest snapshot, not the historical page time. Missing or stale marks produce a null equity point, never an invented zero. Current marks must be no more than 10 seconds old and available on the serving machine. Inspect completeness before using any derived totals:
  • trading is false if fills/positions/balance do not reconcile, fill ordering is ambiguous, values are invalid, or a source exceeds the 50,000-row walk limit. reasons identifies why. A capped response contains partial source data; do not use its totals as final performance.
  • risk describes whether durable risk-event recording covers the whole current cycle. Accounts whose cycle predates deployment return false, even if no surviving breach can be found.
  • currentEquity is false when an open position cannot be valued. Historical samples are independently labelled sampled_not_continuous.
  • unresolvedCommands counts accepted, dispatching, uncertain or unrecognized command states. Any such command blocks advancement even when the visible account currently looks flat.
These reads report the engine’s recorded risk evidence. They do not retrospectively test private firm rules or reconstruct an unrecorded intraday drawdown. Configure your risk controls before trading; evaluate additional business rules in your own backend. An incomplete answer or HTTP error must never be interpreted as permission to advance.

​
Reset boundaries

cycle.startedAt is account creation or its latest reset. A reset starts a new cycle.id, resets trading-day and fill-derived profit calculations, and changes the transition reference. cycle.resetBoundaries records observed reset boundaries from deployment onward. Resets before this feature may not appear in that list; cycle.resetAt still exposes the most recent reset. The paper venue deletes prior-cycle fills when reset, so priorTradingHistoryAvailable is false. Export analytics before an intentional reset if you need that history. Resetting does not clear an active risk lock or an enrollment failure through this API. For a legacy account with incomplete_risk_history, do not automatically reset it to make it pass. Review its history separately. A genuinely new account or an intentionally authorized new reset cycle has forward coverage; old unknown evidence is never silently declared complete.

​
Check a stage

The firm supplies its saved stage policy. profitTarget is a positive amount in account currency with at most two decimal places, not a percentage. minimumTradingDays is an integer from 0 to 3,650. stageId is 1–80 letters, digits, underscores or hyphens and must remain stable across retries. policyId fingerprints those rules and the session definition. Persist it with your decision; do not lower thresholds or change session rules during a retry. eligible: true requires all of the following at the snapshot:
  1. Complete current-cycle trading data and risk-event coverage, and an active issued account.
  2. Net trading profit at or above the target, and at least the minimum qualifying session days.
  3. No open positions, no working orders and no unresolved commands.
  4. No recorded daily-loss, weekly-loss or evaluation breach. Unknown risk reasons also block. Daily/weekly profit locks and end-of-day closes are not treated as disqualifying losses.
  5. An active firm halt, so trading cannot restart while your backend creates the next stage.
A successful check with unmet conditions returns 200, eligible: false, and reasons such as profit_target_not_met, minimum_trading_days_not_met, open_positions, open_orders, unresolved_commands, disqualifying_breach, incomplete_trading_data, incomplete_risk_history, account_not_active or firm_halt_required.

​
Advance safely and retry

The read does not advance, close, reset or reserve an account. Meridian owns the challenge’s stage sequence and its customer communications. Use this sequence in your backend:
  1. Use analytics to detect a candidate that has reached its goals. Check your additional firm rules.
  2. Serialize progression for that challenge in your own database. Halt the old account using the existing partner halt endpoint. Halt prevents new trading; it does not close positions or cancel orders. Resolve remaining activity through your normal authorized workflow, then recheck.
  3. Read eligibility with the saved stage policy. Advance only on a fresh eligible: true result. Keep the old account halted; do not concurrently resume, reset, change risk rules or adjust it.
  4. Persist the decision’s cycleId, stageId, policyId, snapshotId, and transitionReference under a unique constraint on your challenge + cycle + stage. Queue the next-account creation durably in the same transaction, so a backend restart cannot lose it.
  5. Create the next stage account through the existing account API, using the exact transitionReference as its referenceId. If the request times out, retry the same payload and reference. The account API returns the already-created account instead of creating a second one.
  6. Save the returned account number and configure its next-stage risk controls before allowing trading.
The transition reference is stable for the issuing firm, account cycle and stage. A repeated check may return a different eligibility verdict as facts change; it is not a permanent pass certificate. A changed target produces a different policyId but does not create a new transition reference. Retries cannot become an excuse to create another next-stage account under the same stage identity. Use separate stage IDs and preserve the previous account when advancing multiple-stage challenges. On 429, network failures or 5xx, retry with backoff. On 400, correct the parameters. On 401, fix authorization. On 404, check ownership and whether this deployment runs firm-issued accounts. Do not translate any error into a pass. No new eligibility webhook is required: the read is the source for this workflow, and existing fill/risk notifications can prompt your backend to recheck.