> ## Documentation Index > Fetch the complete documentation index at: https://docs.hyperprop.com/llms.txt > Use this file to discover all available pages before exploring further. # Time Machine — revert an account to a trading day > **Time Machine** (outage recovery): restore an account to its **end-of-day state** on the given trading day, in one call — the reverted period stops existing for the trader. **What it does — the reverted period stops existing for the trader:** 1. **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 2. 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) 3. Restores `currentBalance`, `highWaterMark`, and the daily baseline from that snapshot 4. Restores the snapshot's `status` and `violationReason` — an account failed during the bad day comes back to life 5. **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) 6. **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_at` and kept in the database for audit — nothing is deleted. 7. Writes the audit trail (`GET /trading-accounts/{accountId}/changes`), stamps `metadata.last_revert`, and fires `account.updated` (+ status events when the status moved) with `trigger: "trading_day_revert"` 8. 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: true` never 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 | |------|:---:|---------| | `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 | | `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:** ```bash # 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" }' ``` ## OpenAPI ````yaml /api-reference/openapi.json post /v1/organization/accounts/{accountId}/revert-trading-day openapi: 3.0.0 info: title: Hyperprop Platform API version: 1.0.0 description: >- REST API for the Hyperprop Trading Platform — provision evaluation and funded trading accounts, manage traders and plans, react to account lifecycle events via signed webhooks, and reconcile billing. Built for prop firms integrating from their own backend. ## Authentication Two methods, depending on who is calling: ### Bearer Token (JWT) — users & dashboard Most endpoints accept a JWT via `Authorization: Bearer `. Used by the dashboard and client applications. ### API Key — organizations (prop firms) Organization endpoints also accept `X-API-Key: hp_live_...` for programmatic access from your backend — no browser session needed. Keys are managed by organization admins in the dashboard; each key carries permissions (`read`, `write`, `admin`) and can be rotated or revoked at any time. Keys are stored hashed (SHA-256) — the raw key is shown once at creation. Endpoints that create or modify data require `write` or `admin`. ## Quick Start ```bash # 1. List your trading plans (grab a tradingPlanId) curl "https://api.hyperprop.com/platform/v1/organization/trading-plans" \ -H "X-API-Key: hp_live_your_key_here" # 2. Create a trading account for a trader (by Hyperprop user ID or email) curl -X POST "https://api.hyperprop.com/platform/v1/organization/trading-accounts" \ -H "X-API-Key: hp_live_your_key_here" \ -H "Content-Type: application/json" \ -d '{"type": "evaluation", "tradingPlanId": "", "email": "trader@example.com"}' ``` ## Response Envelope & Error Handling **Success** responses always wrap the payload: ```json { "success": true, "data": { ... }, "message": "optional human-readable note" } ``` **Errors** — including request-validation failures, auth failures, and errors proxied from the trade engine — always return this single uniform shape with a machine-readable `code` you can switch on: ```json { "success": false, "statusCode": 404, "error": "Not Found", "message": "No Hyperprop user found with that email. The trader must have a Hyperprop account before an account can be created for them.", "code": "TRADER_NOT_FOUND" } ``` Parse rule of thumb: check `success`; on `false`, switch on `code` (never on `message` text — messages can be reworded). Some errors carry additional structured context alongside these fields (e.g. payout rejections include a `consistency` block). Common codes: `VALIDATION_ERROR` (malformed payload/params), `UNAUTHORIZED`, `INSUFFICIENT_PERMISSIONS` / `NOT_ADMIN` (key lacks write/admin), `*_NOT_FOUND` (missing resource), `*_NOT_IN_ORG` (resource belongs to another organization), `IDEMPOTENCY_KEY_IN_PROGRESS` (duplicate in flight), `ENGINE_UNREACHABLE` (trade engine down — retry with the same idempotency key). Endpoint-specific codes (e.g. payout `OPEN_EXPOSURE`, `CONSISTENCY_BLOCKED`) are documented on each endpoint. ## Idempotency **Every mutating endpoint (POST, PUT, PATCH, DELETE) honors idempotency keys uniformly.** Send an `Idempotency-Key` header (the `X-Idempotency-Key` spelling is accepted as an alias) to retry any write safely without creating duplicates. How it works: - The key is scoped to your organization + the request path. The first request with a given key executes normally and its response is cached for **24 hours**. - A replay (same key, same path) within 24 hours returns the cached response with an `Idempotency-Replayed: true` response header — the operation is **not** executed again. - If a request with the same key is still in flight, the duplicate gets `409 IDEMPOTENCY_KEY_IN_PROGRESS` — back off and retry; you'll then receive the cached response. - 5xx responses are **not** cached, so retrying after a server error re-executes the request (that's what you want). 2xx-4xx responses are cached — if a request failed validation and you fix the payload, use a **fresh key**. - Keys are free-form strings up to 255 characters. Use something that identifies the operation on your side, e.g. `order-8814-attempt-1`. ```bash curl -X POST "https://api.hyperprop.com/platform/v1/organization/trading-accounts" \ -H "X-API-Key: hp_live_your_key_here" \ -H "Idempotency-Key: order-8814-attempt-1" \ -H "Content-Type: application/json" \ -d '{"type": "evaluation", "tradingPlanId": "...", "traderId": "..."}' ``` This applies to account creation, account PATCH (status, currentBalance, metadata), rules, plans, lockouts, payouts, team, webhooks — every write on the platform API. Payouts additionally forward the key to the trade engine for engine-level double-withdrawal protection. ## Pagination & Sorting List endpoints support both styles: - **Cursor (recommended):** pass `?cursor=` from the previous response's `pagination.nextCursor`. Stable under concurrent writes. - **Offset:** `?limit=&offset=` with `pagination.total` / `hasMore` in the response. Sorting uses `?sort=field:direction` (e.g. `?sort=created_at:asc`); allowed fields are listed per endpoint. Default: `created_at:desc`. ## Custom Metadata Trading accounts, purchases, traders, plans, and rules all carry a free-form `metadata` JSON object. Use it to store your own references — payment IDs, campaign tags, payout records, internal notes. Hyperprop stores and returns it verbatim (and lets you filter list endpoints by it, e.g. `?metadata=stripePaymentId:pi_123`) but never interprets it. Update endpoints support `mergeMetadata: true` for shallow (top-level) merges instead of wholesale replacement. ## Webhooks Subscribe to account lifecycle events (`account.created`, `account.status_changed`, `account.updated`, `account.passed`, `account.failed`, and more) via the Webhooks endpoints. Deliveries are HMAC-SHA256 signed — verify `X-Hyperprop-Signature` with your endpoint secret, using `X-Hyperprop-Timestamp` for replay protection; `X-Hyperprop-Delivery` gives you a unique delivery ID for deduplication. Failed deliveries are retried with backoff, and you can redeliver any event from the dashboard or API. ## MCP Connector (AI Agents) The platform ships a built-in [MCP](https://modelcontextprotocol.io) server, so AI agents and assistants (Claude, Cursor, custom agents) can operate your organization directly — no integration code required. ```http Endpoint: POST https://api.hyperprop.com/platform/v1/mcp Transport: Streamable HTTP (stateless, JSON responses) Auth: X-API-Key header, Authorization: Bearer hp_live_..., or OAuth ``` **Claude web / desktop (Add custom connector):** paste the endpoint URL and leave the OAuth Client ID/Secret fields empty — the connector registers itself automatically. Claude opens a Hyperprop consent page where an org admin pastes the organization API key once; access then follows that key's permissions and ends if the key is revoked. (Under the hood: OAuth 2.1 with PKCE and dynamic client registration.) **Cursor / Claude Code — `mcp.json`:** ```json { "mcpServers": { "hyperprop": { "url": "https://api.hyperprop.com/platform/v1/mcp", "headers": { "X-API-Key": "hp_live_your_key_here" } } } } ``` **Available tools (12):** `list_trading_plans`, `list_trading_accounts`, `get_trading_account`, `get_account_audit_log`, `list_traders`, `get_trader`, `list_purchases`, `get_purchase`, `get_billing_summary` (read) · `create_trading_account`, `update_trading_account`, `record_payout` (write). Every tool call executes the corresponding REST endpoint with your key, so organization scoping, permissions, validation, audit logging, and webhooks apply exactly as documented on each endpoint. Read tools work with any key; write tools need `write`/`admin` permission — connect a **read-only key** if you want a strictly read-only agent. `create_trading_account` accepts an optional `idempotencyKey` so agent retries can't create duplicates, and `record_payout` implements the documented payout recipe (append to `metadata.payouts`, adjust `currentBalance`, audit-logged `reason`). ## Endpoint Groups - **Authentication** — Sign up, sign in, OAuth, MFA, password reset. No auth required for most. - **User** — Profile, notifications, demo accounts, audit logs. Requires **Bearer token** (JWT). - **Organization** — Trading accounts, plans, rules, traders, purchases, lockouts, billing, bulk operations, webhooks, analytics. Accepts **Bearer token** OR **API Key**. - **System** — Health checks. No auth required. x-logo: url: https://app.hyperprop.com/logo-icon.svg altText: Hyperprop href: https://hyperprop.com servers: - url: https://api.hyperprop.com/platform description: Production security: [] tags: - name: Authentication description: >- User authentication - signup, signin, signout, password reset, email verification, OAuth, and MFA - name: User description: >- User account management - profile, notifications, agreements, dismissals, and audit logs. Requires Bearer token. - name: Organization description: >- Organization management - profile, team, trading accounts, plans, and rules. Supports **dual authentication**: Bearer JWT token (dashboard users) OR X-API-Key (programmatic access). - name: Demo description: >- Demo account management - import, list, and delete demo trading accounts. Requires Bearer token. - name: Market Data description: CME futures contracts and market data. Requires Bearer token. - name: System description: System endpoints - health checks and connectivity paths: /v1/organization/accounts/{accountId}/revert-trading-day: post: tags: - Organization summary: Time Machine — revert an account to a trading day description: >- **Time Machine** (outage recovery): restore an account to its **end-of-day state** on the given trading day, in one call — the reverted period stops existing for the trader. **What it does — the reverted period stops existing for the trader:** 1. **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 2. 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) 3. Restores `currentBalance`, `highWaterMark`, and the daily baseline from that snapshot 4. Restores the snapshot's `status` and `violationReason` — an account failed during the bad day comes back to life 5. **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) 6. **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_at` and kept in the database for audit — nothing is deleted. 7. Writes the audit trail (`GET /trading-accounts/{accountId}/changes`), stamps `metadata.last_revert`, and fires `account.updated` (+ status events when the status moved) with `trigger: "trading_day_revert"` 8. 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: true` never 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 | |------|:---:|---------| | `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 | | `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:** ```bash # 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" }' ``` operationId: postV1OrganizationAccountsAccountidReverttradingday parameters: - description: Trading account to revert x-format: guid: true name: accountId in: path required: true schema: type: string requestBody: content: application/json: schema: $ref: '#/components/schemas/Model647' responses: '200': description: Account reverted content: '*/*': schema: $ref: '#/components/schemas/Model649' '401': description: Authentication required content: '*/*': schema: $ref: '#/components/schemas/Model7' '403': description: Access denied content: '*/*': schema: $ref: '#/components/schemas/Model39' '404': description: Account not found content: '*/*': schema: $ref: '#/components/schemas/Model650' '500': description: An unexpected error occurred content: '*/*': schema: $ref: '#/components/schemas/Model3' security: - Bearer: [] - X-API-Key: [] components: schemas: Model647: type: object properties: tradingDay: type: string description: >- 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). example: '2026-07-07' pattern: ^\d{4}-\d{2}-\d{2}$ reason: type: string description: >- Why the revert happened — stored in the audit trail, account metadata, and webhook events. example: CME data feed outage on 2026-07-08 minLength: 3 preview: type: boolean description: >- 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. example: true default: false required: - tradingDay - reason Model649: type: object properties: success: type: boolean example: true message: type: string example: Trading day reverted successfully data: $ref: '#/components/schemas/Model648' Model7: type: object properties: success: type: boolean description: Always false on errors example: false statusCode: type: number example: 401 error: type: string example: Unauthorized message: type: string example: Authentication required code: type: string description: Machine-readable error code — switch on this, not on message text example: UNAUTHORIZED Model39: type: object properties: success: type: boolean description: Always false on errors example: false statusCode: type: number example: 403 error: type: string example: Forbidden message: type: string example: Access denied code: type: string description: Machine-readable error code — switch on this, not on message text example: FORBIDDEN Model650: type: object properties: success: type: boolean example: false code: type: string example: ACCOUNT_NOT_FOUND message: type: string example: Account not found in your organization Model3: type: object properties: success: type: boolean description: Always false on errors example: false statusCode: type: number example: 500 error: type: string example: Internal Server Error message: type: string example: An unexpected error occurred code: type: string description: Machine-readable error code — switch on this, not on message text example: INTERNAL_ERROR Model648: type: object example: accountId: 7c9e6679-7425-40de-944b-e07fc1f90ae7 accountNumber: ACC-7845KXPQ revertedTo: '2026-07-07' balanceBefore: 48750 balanceAfter: 51250 statusBefore: failed statusAfter: in_progress snapshotsDeleted: 1 ordersVoided: 14 positionsClosed: 1 ordersCancelled: 2 batchId: f47ac10b-58cc-4372-a567-0e02b2c3d479 preview: false properties: accountId: type: string accountNumber: type: string revertedTo: type: string description: >- Trading day actually restored (latest traded day at/before the requested day), or "initial_state" balanceBefore: type: number balanceAfter: type: number statusBefore: type: string statusAfter: type: string snapshotsDeleted: type: number description: Post-revert daily snapshots voided (archived — restorable by undo) ordersVoided: type: number description: >- Order events after the reverted day voided (hidden from journal/history, kept for audit) positionsClosed: type: number description: >- Open positions force-closed before the revert (their fills are voided too) ordersCancelled: type: number description: Working orders cancelled before the revert batchId: type: string description: >- Time Machine ledger id — list it via GET /revert-batches, undo it via POST /revert-batches/{batchId}/undo. null in previews. preview: type: boolean description: true = dry run, nothing was changed securitySchemes: Bearer: type: apiKey name: Authorization in: header description: >- JWT Bearer token for user session auth. Format: "Bearer {token}". Used by User and Organization endpoints. X-API-Key: type: apiKey name: X-API-Key in: header description: >- Organization API key for programmatic access. Format: "hp_live_{key}". Used by Organization endpoints as an alternative to Bearer token. Keys are managed in the dashboard. ```` ## Related topics - [Time Machine — bulk revert accounts to a trading day](/platform-api/organization/time-machine-—-bulk-revert-accounts-to-a-trading-day.md) - [Time Machine — list revert batches](/platform-api/organization/time-machine-—-list-revert-batches.md) - [Time Machine — undo a revert batch](/platform-api/organization/time-machine-—-undo-a-revert-batch.md) - [Time Machine — inspect a revert batch](/platform-api/organization/time-machine-—-inspect-a-revert-batch.md) - [List roles (system presets + your custom roles)](/platform-api/organization/list-roles-system-presets-+-your-custom-roles.md)