Time Machine — 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 last end-of-day snapshot before the instant’s trading day, rolled forward through the fills booked up to the instant. Fills since 2026-09-08 carry the engine-stamped post-fill balance, so the restored balance is the one the trader actually had; older fills are summed the way the engine books them (realized − fee − commission). 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 (rows 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 rows are stamped
reverted_atand kept in the database 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" - Pushes the restored state into the live trade engine and notifies the trader’s open terminal (balances, history, and journal update in real time with an explanatory toast)
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": "CME data feed outage on 2026-07-08", "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": "CME data feed outage on 2026-07-08" }'
Authorizations
JWT Bearer token for user session auth. Format: "Bearer {token}". Used by User and Organization endpoints.
Path Parameters
Trading account to revert
Body
Why the revert happened — stored in the audit trail, account metadata, and webhook events.
3"CME data feed outage on 2026-07-08"
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 its state at that instant: the last end-of-day snapshot before that trading day, rolled forward through the fills booked up to the instant (engine-stamped post-fill balances where available), 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
Related topics
Time Machine — bulk revert accounts to a trading day or an instantTime Machine — list revert batchesTime Machine — inspect a revert batchChangelogTime Machine — undo a revert batch