Revert an account to a trading day or an instant
Time Machine (outage recovery): restore an account to its end-of-day state on the given trading day — or, with revertTo, to its exact state at an instant (the moment an outage began) — in one call. The reverted period stops existing for the trader.
Two ways to name the restore point
| Field | Restores to | Cutoff (everything after is voided) |
|---|---|---|
tradingDay | the end-of-day snapshot of that Chicago trading day (or the latest traded day before it) | that day’s 17:00 America/Chicago close |
revertTo | the account’s state at that instant: the balance the trader had at that moment, including every fill up to it. The high-water mark follows the plan’s drawdown type (intraday-trailing plans take the highest balance on the way; end-of-day plans keep the base close). The status is the one in force at the instant (an account that failed later comes back to life). | the instant itself |
What it does — the reverted period stops existing for the trader:
- Closes any open positions and cancels all working orders first (reason: “Trading day reverted by your firm: …”) — no live exposure survives into the reverted world, and the closing fills land inside the voided window so they are erased too
- Loads the account’s end-of-day snapshot for
tradingDay(or the latest traded day before it — e.g. reverting to a Sunday uses Friday’s close) - Restores
currentBalance,highWaterMark, and the daily baseline from that snapshot - Restores the snapshot’s
statusandviolationReason— an account failed during the bad day comes back to life - Voids the daily snapshots after the target day for this account, so consistency checks and daily-stats endpoints no longer see the reverted days (they are archived, not destroyed)
- Voids every order and fill after the reverted day’s close (17:00 America/Chicago): they disappear from the trader’s journal, order history, and trade blotter, and the account’s performance stats (trade count, win rate) are recomputed from the surviving fills. Voided activity is kept for audit — nothing is deleted.
- Writes the audit trail (
GET /trading-accounts/{accountId}/changes), stampsmetadata.last_revert, and firesaccount.updated(+ status events when the status moved) withtrigger: "trading_day_revert" - Applies the restored state immediately and updates the trader’s open terminal in real time (balances, history, and journal), with an explanatory notice
If the account had never traded on or before the target day (e.g. it was created during the outage day itself), it is restored to its pristine initial state — starting balance, in_progress, entire order history voided. The account keeps existing; reverting never deletes accounts.
Undoable. Every executed revert returns a batchId and appears in the Time Machine ledger (GET /revert-batches). Nothing a revert touches is destroyed, so if you reverted by mistake, POST /revert-batches/{batchId}/undo puts the account back exactly where it was — as long as the trader hasn’t produced new activity since (see that endpoint for the rules).
Notes:
preview: truenever touches positions — the flatten only happens on execute.- Consistency: reverted days are removed from the day list automatically (their snapshots are voided).
Recommended flow (calendar UI): call with "preview": true first to show the operator what will happen (restored balance, status transition, orders voided), then call again without preview to execute.
Error codes:
| Code | Status | Meaning |
|---|---|---|
INVALID_REVERT_POINT | 400 | Neither/both of tradingDay and revertTo, revertTo not a timestamp, or revertTo in the future |
ACCOUNT_NOT_FOUND | 404 | Account does not exist or belongs to a different organization |
SNAPSHOT_FETCH_ERROR | 500 | Could not read the account’s daily snapshots — retry |
BALANCE_AT_INSTANT_ERROR | 500 | Could not read the fills needed to roll the balance forward to revertTo — retry |
SNAPSHOT_DELETE_ERROR | 500 | Failed to void post-revert snapshots — retry (idempotent) |
REVERT_UPDATE_ERROR | 500 | Failed to write the restored account state — retry (idempotent) |
The revert is safe to retry: every step is idempotent (already-voided rows keep their original stamp, and the state write is absolute).
Example — preview, then execute:
# 1. Dry run — nothing changes
curl -X POST ".../v1/organization/accounts/7c9e6679-7425-40de-944b-e07fc1f90ae7/revert-trading-day" \
-H "X-API-Key: hp_live_your_key_here" \
-H "Content-Type: application/json" \
-d '{ "tradingDay": "2026-07-07", "reason": "Data feed outage", "preview": true }'
# 2. Execute
curl -X POST ".../v1/organization/accounts/7c9e6679-7425-40de-944b-e07fc1f90ae7/revert-trading-day" \
-H "X-API-Key: hp_live_your_key_here" \
-H "Content-Type: application/json" \
-d '{ "tradingDay": "2026-07-07", "reason": "Data feed outage" }'
Authorizations
Organization API key. Format: "hp_live_{key}". Organization admins manage the key in the dashboard.
Path Parameters
Trading account to revert
Body
Why the revert happened — stored in the audit trail, account metadata, and webhook events.
3"Data feed outage"
END-OF-DAY restore: Chicago trading day (YYYY-MM-DD) to revert TO. The account is restored to its end-of-day state on this day (or the latest traded day before it). Provide either tradingDay or revertTo.
^\d{4}-\d{2}-\d{2}$"2026-07-07"
POINT-IN-TIME restore: the exact instant (ISO 8601, UTC) to revert TO — e.g. the moment an outage began. The account is restored to the state it had at that instant, with everything after the instant voided. Provide either tradingDay or revertTo.
"2026-09-08T13:30:00Z"
Dry run: return exactly what the revert WOULD do (target day, balances, status transition, snapshots removed, orders voided) without changing anything. Perfect for an "are you sure?" confirmation screen.
true