> ## 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. # Register a webhook endpoint > Register a URL to receive real-time event notifications via HTTP POST. **How it works:** 1. You provide an HTTPS URL and choose which events to subscribe to 2. Hyperprop returns a signing secret (shown **once** — save it) 3. When events occur, we POST a JSON payload to your URL with an HMAC-SHA256 signature 4. Verify the signature using the secret to ensure the payload is authentic **Available events:** | Event | Description | |-------|-------------| | `account.created` | A new trading account was provisioned | | `account.status_changed` | Account status changed (not_started → in_progress → passed/failed/expired) | | `account.updated` | Account fields updated (balance, metadata, HWM) | | `account.imported` | A trader redeemed an import key inside the Hyperprop app — the account now has its owner. Payload carries an `import` block: `{ importKey, importedUserId, importedEmail, importedAt }` so you can verify who redeemed which key and when. Billing + market data start at this moment. **Store `import.importedEmail` on your customer's profile** — that login is now soulbound to the account's `customerId` and all the customer's future imports must use it (see GET /trader-bindings). | | `account.unlinked` | You unlinked a not-yet-started account via POST /trading-accounts/{accountId}/unlink. Payload carries an `import` block: `{ voidedImportKey, newImportKey, unlinkedUserId, unlinkedEmail }` — the fresh key is ready to hand out. Note: the customer's soulbound binding survives unlink — if the customer needs a new Hyperprop login, rebind them via POST /trader-bindings/{bindingId}/rebind. | | `account.passed` | Account passed — profit target reached or admin update (convenience — also fires `account.status_changed`) | | `account.failed` | Account failed — **live rule violation** (max loss, daily loss, drawdown…) or admin update (convenience — also fires `account.status_changed`) | | `account.lockout_created` | Trading lockout applied to an account | | `account.lockout_removed` | Trading lockout removed from an account | | `account.lockout_updated` | Lockout details changed (reason, end time) | | `account.payout_processed` | A payout (balance withdrawal) was executed on an account | | `account.max_payouts_reached` | The account reached its rule's `maxPayouts` with this payout — your "move trader to live" trigger | | `purchase.created` | A new purchase was recorded for the organization | | `purchase.status_changed` | Purchase status changed (pending → paid, paid → refunded/cancelled) | | `trader.created` | A new trader was associated with the organization | | `snapshot.ready` | End-of-day snapshots for a trading day are computed and queryable — fire your EOD import off this instead of guessing a time | | `fill.created` | An order was filled — near-real-time intraday fill stream (**explicit subscription only**, see below) | Use `["*"]` to subscribe to all events (including future event types). **Exception:** `fill.created` is high-volume and is **never** delivered through a `["*"]` wildcard — an endpoint must list it explicitly in its `events` array to receive fills. **Fills are not recorded until you subscribe.** Because a wildcard cannot opt you into fills, fill events are only written for organizations that have an active endpoint explicitly listing `fill.created`. Adding it starts the stream within seconds, but fills that occurred *before* you subscribed are **not** backfilled — webhooks are forward-looking. Subscribe before you need the history, or read fills from `GET /platform/v1/organization/reconciliation` for any past day. **snapshot.ready:** fires **once per organization per trading day**, right after the trade engine writes the EOD batch (shortly after CME close, 16:00 CT). Payload: ```json { "id": "evt_2c1d...", "type": "snapshot.ready", "organizationId": "a6fcc0ce-...", "data": { "tradingDay": "2026-07-22", "accountsSnapshotted": 142, "snapshotsUrl": "/platform/v1/organization/snapshots/accounts?tradingDay=2026-07-22", "fillsUrl": "/platform/v1/organization/snapshots/fills?tradingDay=2026-07-22" } } ``` On receipt, call `GET /snapshots/accounts?tradingDay=...` — the data is guaranteed to be there. If you prefer polling, the snapshots endpoint also returns `latestCompletedTradingDay`. **fill.created:** fires within seconds of an order being filled, so intraday trade tracking and profitable-day updates don't have to wait for the EOD batch. Requires explicit subscription (never delivered via `["*"]`, and not recorded at all until at least one active endpoint lists it — no backfill). Expect one event per fill per account, so size your endpoint for your real fill rate. The same events also stream over the WebSocket at `/organization/events/stream` for connected clients. Payload: ```json { "id": "evt_9f3a...", "type": "fill.created", "organizationId": "a6fcc0ce-...", "data": { "orderId": "0d1e...", "contract": "MNQZ6", "product": "MNQ", "symbol": "MNQ", "side": "buy", "orderType": "market", "quantity": 2, "filledQuantity": 2, "filledPrice": 21150.25, "fee": 0.74, "commission": 0.5, "realizedPnl": null, "filledAt": "2026-07-22T14:03:11.482Z", "account": { "id": "...", "accountNumber": "MFFU-1042", "customerId": "your-customer-id", "status": "in_progress", "currentBalance": 104250 }, "trader": { "email": "trader@example.com", "externalUserId": "your-user-id" } } } ``` **Payout events:** `account.payout_processed` fires on every executed payout with the amounts and options applied in a `payout` block: ```json { "id": "evt_7b2c...", "type": "account.payout_processed", "data": { "id": "...", "status": "in_progress", "...": "..." }, "payout": { "payout_id": "e5f6a7b8-c9d0-1234-ef01-234567890abc", "amount": 1600.0, "balance_before": 52500.0, "balance_after": 50900.0, "payout_count": 1, "mll_locked_to": 50100.0, "consistency_reset": true } } ``` `account.max_payouts_reached` fires once, alongside the payout that hits the rule's `maxPayouts` limit, carrying `payout.payout_id` and `payout.payout_count`. **Limits:** Maximum 5 webhooks per organization. **Payload format:** Each event includes the full trading account object (`data`) plus `previousAttributes` showing what changed. Where available, `data` includes event-time account context such as trader, trading plan, trading rule, purchase, and active lockout details. See the webhook documentation for full payload schemas. **Rule violation alerts:** Subscribe to `account.failed` to be alerted the moment the trading engine fails an account. Violation events carry structured context: | Field | Description | Example | |-------|-------------|---------| | `trigger` | What caused the event | `rule_violation`, `profit_target`, `admin_bulk` | | `ruleType` | Which rule fired (violations only) | `max_loss`, `daily_loss`, `max_drawdown`, `daily_drawdown` | | `data.violationReason` | Human-readable explanation | `"Max Loss exceeded: $2,514.00 loss >= $2500 limit"` | ```json { "id": "evt_5f8a...", "type": "account.failed", "trigger": "rule_violation", "ruleType": "daily_loss", "data": { "id": "...", "status": "failed", "violationReason": "Daily Loss exceeded: $1,012.50 loss >= $1000 limit", "...": "..." }, "previousAttributes": null } ``` **Signature verification:** ```javascript const crypto = require('crypto'); function verify(rawBody, signature, secret, timestamp) { if (Math.abs(Date.now() / 1000 - timestamp) > 300) return false; // replay protection const expected = 'sha256=' + crypto.createHmac('sha256', secret) .update(timestamp + '.' + rawBody).digest('hex'); return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected)); } ``` **Authentication:** Accepts either `Authorization: Bearer ` (dashboard) or `X-API-Key: hp_live_...` (programmatic). ## OpenAPI ````yaml /api-reference/openapi.json post /v1/organization/webhooks 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/webhooks: post: tags: - Organization summary: Register a webhook endpoint description: >- Register a URL to receive real-time event notifications via HTTP POST. **How it works:** 1. You provide an HTTPS URL and choose which events to subscribe to 2. Hyperprop returns a signing secret (shown **once** — save it) 3. When events occur, we POST a JSON payload to your URL with an HMAC-SHA256 signature 4. Verify the signature using the secret to ensure the payload is authentic **Available events:** | Event | Description | |-------|-------------| | `account.created` | A new trading account was provisioned | | `account.status_changed` | Account status changed (not_started → in_progress → passed/failed/expired) | | `account.updated` | Account fields updated (balance, metadata, HWM) | | `account.imported` | A trader redeemed an import key inside the Hyperprop app — the account now has its owner. Payload carries an `import` block: `{ importKey, importedUserId, importedEmail, importedAt }` so you can verify who redeemed which key and when. Billing + market data start at this moment. **Store `import.importedEmail` on your customer's profile** — that login is now soulbound to the account's `customerId` and all the customer's future imports must use it (see GET /trader-bindings). | | `account.unlinked` | You unlinked a not-yet-started account via POST /trading-accounts/{accountId}/unlink. Payload carries an `import` block: `{ voidedImportKey, newImportKey, unlinkedUserId, unlinkedEmail }` — the fresh key is ready to hand out. Note: the customer's soulbound binding survives unlink — if the customer needs a new Hyperprop login, rebind them via POST /trader-bindings/{bindingId}/rebind. | | `account.passed` | Account passed — profit target reached or admin update (convenience — also fires `account.status_changed`) | | `account.failed` | Account failed — **live rule violation** (max loss, daily loss, drawdown…) or admin update (convenience — also fires `account.status_changed`) | | `account.lockout_created` | Trading lockout applied to an account | | `account.lockout_removed` | Trading lockout removed from an account | | `account.lockout_updated` | Lockout details changed (reason, end time) | | `account.payout_processed` | A payout (balance withdrawal) was executed on an account | | `account.max_payouts_reached` | The account reached its rule's `maxPayouts` with this payout — your "move trader to live" trigger | | `purchase.created` | A new purchase was recorded for the organization | | `purchase.status_changed` | Purchase status changed (pending → paid, paid → refunded/cancelled) | | `trader.created` | A new trader was associated with the organization | | `snapshot.ready` | End-of-day snapshots for a trading day are computed and queryable — fire your EOD import off this instead of guessing a time | | `fill.created` | An order was filled — near-real-time intraday fill stream (**explicit subscription only**, see below) | Use `["*"]` to subscribe to all events (including future event types). **Exception:** `fill.created` is high-volume and is **never** delivered through a `["*"]` wildcard — an endpoint must list it explicitly in its `events` array to receive fills. **Fills are not recorded until you subscribe.** Because a wildcard cannot opt you into fills, fill events are only written for organizations that have an active endpoint explicitly listing `fill.created`. Adding it starts the stream within seconds, but fills that occurred *before* you subscribed are **not** backfilled — webhooks are forward-looking. Subscribe before you need the history, or read fills from `GET /platform/v1/organization/reconciliation` for any past day. **snapshot.ready:** fires **once per organization per trading day**, right after the trade engine writes the EOD batch (shortly after CME close, 16:00 CT). Payload: ```json { "id": "evt_2c1d...", "type": "snapshot.ready", "organizationId": "a6fcc0ce-...", "data": { "tradingDay": "2026-07-22", "accountsSnapshotted": 142, "snapshotsUrl": "/platform/v1/organization/snapshots/accounts?tradingDay=2026-07-22", "fillsUrl": "/platform/v1/organization/snapshots/fills?tradingDay=2026-07-22" } } ``` On receipt, call `GET /snapshots/accounts?tradingDay=...` — the data is guaranteed to be there. If you prefer polling, the snapshots endpoint also returns `latestCompletedTradingDay`. **fill.created:** fires within seconds of an order being filled, so intraday trade tracking and profitable-day updates don't have to wait for the EOD batch. Requires explicit subscription (never delivered via `["*"]`, and not recorded at all until at least one active endpoint lists it — no backfill). Expect one event per fill per account, so size your endpoint for your real fill rate. The same events also stream over the WebSocket at `/organization/events/stream` for connected clients. Payload: ```json { "id": "evt_9f3a...", "type": "fill.created", "organizationId": "a6fcc0ce-...", "data": { "orderId": "0d1e...", "contract": "MNQZ6", "product": "MNQ", "symbol": "MNQ", "side": "buy", "orderType": "market", "quantity": 2, "filledQuantity": 2, "filledPrice": 21150.25, "fee": 0.74, "commission": 0.5, "realizedPnl": null, "filledAt": "2026-07-22T14:03:11.482Z", "account": { "id": "...", "accountNumber": "MFFU-1042", "customerId": "your-customer-id", "status": "in_progress", "currentBalance": 104250 }, "trader": { "email": "trader@example.com", "externalUserId": "your-user-id" } } } ``` **Payout events:** `account.payout_processed` fires on every executed payout with the amounts and options applied in a `payout` block: ```json { "id": "evt_7b2c...", "type": "account.payout_processed", "data": { "id": "...", "status": "in_progress", "...": "..." }, "payout": { "payout_id": "e5f6a7b8-c9d0-1234-ef01-234567890abc", "amount": 1600.0, "balance_before": 52500.0, "balance_after": 50900.0, "payout_count": 1, "mll_locked_to": 50100.0, "consistency_reset": true } } ``` `account.max_payouts_reached` fires once, alongside the payout that hits the rule's `maxPayouts` limit, carrying `payout.payout_id` and `payout.payout_count`. **Limits:** Maximum 5 webhooks per organization. **Payload format:** Each event includes the full trading account object (`data`) plus `previousAttributes` showing what changed. Where available, `data` includes event-time account context such as trader, trading plan, trading rule, purchase, and active lockout details. See the webhook documentation for full payload schemas. **Rule violation alerts:** Subscribe to `account.failed` to be alerted the moment the trading engine fails an account. Violation events carry structured context: | Field | Description | Example | |-------|-------------|---------| | `trigger` | What caused the event | `rule_violation`, `profit_target`, `admin_bulk` | | `ruleType` | Which rule fired (violations only) | `max_loss`, `daily_loss`, `max_drawdown`, `daily_drawdown` | | `data.violationReason` | Human-readable explanation | `"Max Loss exceeded: $2,514.00 loss >= $2500 limit"` | ```json { "id": "evt_5f8a...", "type": "account.failed", "trigger": "rule_violation", "ruleType": "daily_loss", "data": { "id": "...", "status": "failed", "violationReason": "Daily Loss exceeded: $1,012.50 loss >= $1000 limit", "...": "..." }, "previousAttributes": null } ``` **Signature verification:** ```javascript const crypto = require('crypto'); function verify(rawBody, signature, secret, timestamp) { if (Math.abs(Date.now() / 1000 - timestamp) > 300) return false; // replay protection const expected = 'sha256=' + crypto.createHmac('sha256', secret) .update(timestamp + '.' + rawBody).digest('hex'); return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected)); } ``` **Authentication:** Accepts either `Authorization: Bearer ` (dashboard) or `X-API-Key: hp_live_...` (programmatic). operationId: postV1OrganizationWebhooks requestBody: content: application/json: schema: $ref: '#/components/schemas/Model531' responses: '201': description: >- Webhook created — the signing secret is included in this response **only** content: '*/*': schema: $ref: '#/components/schemas/Model534' '400': description: Validation error — invalid URL, events, or webhook limit reached content: '*/*': schema: $ref: '#/components/schemas/Model535' '401': description: Authentication required content: '*/*': schema: $ref: '#/components/schemas/Model7' '403': description: Access denied content: '*/*': schema: $ref: '#/components/schemas/Model39' '500': description: An unexpected error occurred content: '*/*': schema: $ref: '#/components/schemas/Model3' security: - Bearer: [] - X-API-Key: [] components: schemas: Model531: type: object properties: url: type: string description: Webhook endpoint URL. Must be HTTPS. example: https://your-server.com/webhooks/hyperprop x-format: uri: scheme: https events: $ref: '#/components/schemas/Model530' description: type: string description: Optional label (e.g. "Production", "Staging CRM") example: Production webhook maxLength: 255 required: - url - events Model534: type: object properties: success: type: boolean example: true data: $ref: '#/components/schemas/Model533' message: type: string example: Webhook created. Save your signing secret — it won't be shown again. Model535: type: object properties: success: type: boolean description: Always false on errors example: false statusCode: type: number example: 400 error: type: string example: Bad Request message: type: string example: Maximum 5 webhooks per organization code: type: string description: Machine-readable error code — switch on this, not on message text example: WEBHOOK_LIMIT_REACHED 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 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 Model530: type: array description: >- Event types to subscribe to. Use ["*"] for all current and future events. example: - account.created - account.status_changed minItems: 1 items: $ref: '#/components/schemas/Model529' Model533: type: object properties: id: type: string description: Unique webhook ID example: d2f3a1c0-8e7b-4f6a-9c5d-1234567890ab x-format: guid: true url: type: string description: Endpoint URL that receives webhook POSTs example: https://your-server.com/webhooks/hyperprop x-format: uri: true events: $ref: '#/components/schemas/Model532' description: type: string description: Optional label to identify this webhook example: Production webhook isActive: type: boolean description: >- Whether the webhook is currently active. Disabled webhooks receive no events. example: true failureCount: type: number description: >- Consecutive delivery failures. Resets to 0 on any successful delivery or re-enable. Auto-disables at 25. example: 0 disabledAt: type: string description: Timestamp when the webhook was auto-disabled, if applicable. example: '2026-03-28T22:00:00.000Z' disabledReason: type: string description: Reason the webhook was disabled, if applicable. example: Auto-disabled after 25 consecutive delivery failures lastTriggeredAt: type: string description: Timestamp of the last delivery attempt example: '2026-03-28T21:30:00.000Z' createdAt: type: string example: '2026-03-28T21:00:00.000Z' updatedAt: type: string example: '2026-03-28T21:30:00.000Z' secret: type: string description: >- HMAC-SHA256 signing secret. **Only returned on creation and rotation.** Save it — you cannot retrieve it later. example: >- whsec_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2 Model529: type: string enum: - '*' - account.created - account.status_changed - account.updated - account.imported - account.unlinked - account.passed - account.failed - account.lockout_created - account.lockout_removed - account.lockout_updated - account.payout_processed - account.max_payouts_reached - purchase.created - purchase.status_changed - trader.created - snapshot.ready - fill.created Model532: type: array description: Event types this webhook subscribes to. Use ["*"] for all. example: - account.created - account.status_changed items: type: string 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 - [Get webhook endpoint delivery and latency metrics](/platform-api/organization/get-webhook-endpoint-delivery-and-latency-metrics.md) - [Webhooks](/guides/webhooks.md) - [MCP connector (AI agents)](/guides/mcp-connector.md) - [Delete a webhook](/platform-api/organization/delete-a-webhook.md) - [Update a webhook](/platform-api/organization/update-a-webhook.md)