> ## 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 executed quantity — fires once when the order reaches a terminal state: fully `filled`, or `cancelled`/`rejected`/`expired` after a partial execution. Near-real-time intraday fill stream (**explicit subscription only**, see below) | | `account.balance_changed` | The account's balance moved. One event per change with `previousBalance`, `currentBalance`, `change`, `reason` (`fill` · `payout` · `revert` · `adjustment`), `orderId` / `payoutId` where applicable and `occurredAt`. Same id and values on the WebSocket frame and the `?since=` replay, so you can dedupe across channels on `id`. **Explicit subscription only** (see below) | Use `["*"]` to subscribe to all events (including future event types). **Exception:** `fill.created` and `account.balance_changed` are high-volume and are **never** delivered through a `["*"]` wildcard — an endpoint must list them explicitly in its `events` array. **account.balance_changed** is the one event to follow if you keep your own copy of balances: every fill, payout, adjustment and trading-day revert produces exactly one. Payload: ```json { "id": "evt_9f1c...", "type": "account.balance_changed", "createdAt": "2026-09-09T20:14:08.412Z", "organizationId": "a6fcc0ce-...", "data": { "previousBalance": 25434.67, "currentBalance": 25806.63, "change": 371.96, "reason": "fill", "orderId": "efd59f41-09c5-4bf4-9378-78f70f115a16", "payoutId": null, "occurredAt": "2026-09-09T20:14:08.107Z", "account": { "id": "ddf46c59-...", "accountNumber": "ACMEEV...", "customerId": "1e38d177-...", "status": "in_progress", "currentBalance": 25806.63 }, "trader": { "email": "trader@example.com", "name": "…", "externalUserId": null, "metadata": {} } }, "previousAttributes": { "currentBalance": 25434.67 } } ``` Like fills, balance webhooks are only recorded while an active endpoint lists `account.balance_changed`; the WebSocket stream delivers and replays them regardless. Reconcile against `GET /platform/v1/organization/balances` on your own schedule. **Fill webhooks are not recorded until you subscribe.** Because a wildcard cannot opt you into fills, fill *webhook* deliveries are only written for organizations that have an active endpoint explicitly listing `fill.created`. Adding it starts webhook delivery within seconds, but fills that occurred *before* you subscribed are **not** re-delivered — webhooks are forward-looking. This gate applies to the webhook channel only: the WebSocket event stream delivers and replays fills regardless of webhook configuration. For history, read fills from `GET /platform/v1/organization/reconciliation` for any past day. **snapshot.ready:** fires **once per organization per trading day**, as soon as that day's end-of-day snapshots are available (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 reaching a **terminal state with executed quantity** — a complete fill (`status: "filled"`), or an order that partially executed and was then cancelled, rejected, or expired. Exactly one event per executed order, carrying the final totals: `filledQuantity` is the cumulative executed quantity (may be **less than** `quantity` for a final partial), `filledPrice` is the volume-weighted average across all executions of the order, and `fee`/`commission`/`realizedPnl` are the accumulated totals. Check `status` to distinguish a final partial from a complete fill; dedupe on `orderId`. (In the rare case an order first reported as cancelled turns out to have filled, a second event with the same `orderId` and updated totals is emitted — treat the latest as authoritative.) Requires explicit webhook subscription (never delivered via `["*"]`; webhook event records only start once an active endpoint lists it). The same events always stream over the WebSocket at `/organization/events/stream` regardless of webhook configuration — see that endpoint for its delivery guarantees. Expect one event per executed order per account, so size your endpoint for your real fill rate. Payload: ```json { "id": "evt_9f3a...", "type": "fill.created", "organizationId": "a6fcc0ce-...", "data": { "orderId": "0d1e...", "contract": "MNQZ6", "product": "MNQ", "symbol": "MNQ", "side": "buy", "orderType": "market", "status": "filled", "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": "ACME-1042", "customerId": "your-customer-id", "status": "in_progress", "currentBalance": 104250 }, "trader": { "email": "trader@example.com", "externalUserId": "your-user-id" } } } ``` A partial-then-cancelled order looks like `"status": "cancelled", "quantity": 3, "filledQuantity": 1` — one contract really executed (balance, P&L, and fees reflect it), so record it as a fill of 1. **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:** send your organization API key in the `X-API-Key` header. ## 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, quick start, error handling, idempotency, pagination, custom metadata, webhooks, and the MCP connector are documented at https://docs.hyperprop.com. 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: Trading accounts description: Create, update, and inspect trading accounts. - name: Traders description: Look up and update the traders in your organization. - name: Trading plans description: Define the plans you sell. - name: Trading rules description: Define how accounts are evaluated. - name: Lockouts description: Pause and resume trading on an account. - name: Payouts description: Check payout eligibility and record payouts. - name: Purchases description: Purchases recorded for your organization. - name: Time Machine description: Restore accounts to an earlier trading day or instant. - name: Webhooks description: Register webhook endpoints and inspect deliveries. - name: Events description: Your organization's event history and real-time event stream. - name: Reconciliation description: Balances, end-of-day snapshots, and fills for reconciliation. - name: Analytics description: Organization performance and plan economics. - name: Billing description: 'Your Hyperprop bill: activity, billing cycles, and forecasts.' - name: Team and roles description: Manage dashboard access for your staff. - name: API keys description: Manage your organization's API key. - name: Logs and health description: API request logs, the audit log, and integration health. - name: Organization profile description: Your organization's profile and logo. - name: Support description: Open and follow up on support tickets. - name: Partner access description: >- Read a trader's journal as an approved partner app, with the trader's own key. paths: /v1/organization/webhooks: post: tags: - Webhooks 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 executed quantity — fires once when the order reaches a terminal state: fully `filled`, or `cancelled`/`rejected`/`expired` after a partial execution. Near-real-time intraday fill stream (**explicit subscription only**, see below) | | `account.balance_changed` | The account's balance moved. One event per change with `previousBalance`, `currentBalance`, `change`, `reason` (`fill` · `payout` · `revert` · `adjustment`), `orderId` / `payoutId` where applicable and `occurredAt`. Same id and values on the WebSocket frame and the `?since=` replay, so you can dedupe across channels on `id`. **Explicit subscription only** (see below) | Use `["*"]` to subscribe to all events (including future event types). **Exception:** `fill.created` and `account.balance_changed` are high-volume and are **never** delivered through a `["*"]` wildcard — an endpoint must list them explicitly in its `events` array. **account.balance_changed** is the one event to follow if you keep your own copy of balances: every fill, payout, adjustment and trading-day revert produces exactly one. Payload: ```json { "id": "evt_9f1c...", "type": "account.balance_changed", "createdAt": "2026-09-09T20:14:08.412Z", "organizationId": "a6fcc0ce-...", "data": { "previousBalance": 25434.67, "currentBalance": 25806.63, "change": 371.96, "reason": "fill", "orderId": "efd59f41-09c5-4bf4-9378-78f70f115a16", "payoutId": null, "occurredAt": "2026-09-09T20:14:08.107Z", "account": { "id": "ddf46c59-...", "accountNumber": "ACMEEV...", "customerId": "1e38d177-...", "status": "in_progress", "currentBalance": 25806.63 }, "trader": { "email": "trader@example.com", "name": "…", "externalUserId": null, "metadata": {} } }, "previousAttributes": { "currentBalance": 25434.67 } } ``` Like fills, balance webhooks are only recorded while an active endpoint lists `account.balance_changed`; the WebSocket stream delivers and replays them regardless. Reconcile against `GET /platform/v1/organization/balances` on your own schedule. **Fill webhooks are not recorded until you subscribe.** Because a wildcard cannot opt you into fills, fill *webhook* deliveries are only written for organizations that have an active endpoint explicitly listing `fill.created`. Adding it starts webhook delivery within seconds, but fills that occurred *before* you subscribed are **not** re-delivered — webhooks are forward-looking. This gate applies to the webhook channel only: the WebSocket event stream delivers and replays fills regardless of webhook configuration. For history, read fills from `GET /platform/v1/organization/reconciliation` for any past day. **snapshot.ready:** fires **once per organization per trading day**, as soon as that day's end-of-day snapshots are available (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 reaching a **terminal state with executed quantity** — a complete fill (`status: "filled"`), or an order that partially executed and was then cancelled, rejected, or expired. Exactly one event per executed order, carrying the final totals: `filledQuantity` is the cumulative executed quantity (may be **less than** `quantity` for a final partial), `filledPrice` is the volume-weighted average across all executions of the order, and `fee`/`commission`/`realizedPnl` are the accumulated totals. Check `status` to distinguish a final partial from a complete fill; dedupe on `orderId`. (In the rare case an order first reported as cancelled turns out to have filled, a second event with the same `orderId` and updated totals is emitted — treat the latest as authoritative.) Requires explicit webhook subscription (never delivered via `["*"]`; webhook event records only start once an active endpoint lists it). The same events always stream over the WebSocket at `/organization/events/stream` regardless of webhook configuration — see that endpoint for its delivery guarantees. Expect one event per executed order per account, so size your endpoint for your real fill rate. Payload: ```json { "id": "evt_9f3a...", "type": "fill.created", "organizationId": "a6fcc0ce-...", "data": { "orderId": "0d1e...", "contract": "MNQZ6", "product": "MNQ", "symbol": "MNQ", "side": "buy", "orderType": "market", "status": "filled", "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": "ACME-1042", "customerId": "your-customer-id", "status": "in_progress", "currentBalance": 104250 }, "trader": { "email": "trader@example.com", "externalUserId": "your-user-id" } } } ``` A partial-then-cancelled order looks like `"status": "cancelled", "quantity": 3, "filledQuantity": 1` — one contract really executed (balance, P&L, and fees reflect it), so record it as a fill of 1. **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:** send your organization API key in the `X-API-Key` header. operationId: postV1OrganizationWebhooks requestBody: content: application/json: schema: $ref: '#/components/schemas/Model595' responses: '201': description: >- Webhook created — the signing secret is included in this response **only** content: '*/*': schema: $ref: '#/components/schemas/Model598' '400': description: Validation error — invalid URL, events, or webhook limit reached content: '*/*': schema: $ref: '#/components/schemas/Model599' '401': description: Authentication required content: '*/*': schema: $ref: '#/components/schemas/Model9' '403': description: Access denied content: '*/*': schema: $ref: '#/components/schemas/Model47' '500': description: An unexpected error occurred content: '*/*': schema: $ref: '#/components/schemas/Model5' security: - X-API-Key: [] components: schemas: Model595: 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/Model594' description: type: string description: Optional label (e.g. "Production", "Staging CRM") example: Production webhook maxLength: 255 required: - url - events Model598: type: object properties: success: type: boolean example: true data: $ref: '#/components/schemas/Model597' message: type: string example: Webhook created. Save your signing secret — it won't be shown again. Model599: 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 Model9: 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 Model47: 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 Model5: 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 Model594: 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/Model593' Model597: 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/Model596' 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 Model593: 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 - account.balance_changed Model596: type: array description: Event types this webhook subscribes to. Use ["*"] for all. example: - account.created - account.status_changed items: type: string securitySchemes: X-API-Key: type: apiKey name: X-API-Key in: header description: >- Organization API key. Format: "hp_live_{key}". Organization admins manage the key in the dashboard. ```` ## Related topics - [Get webhook endpoint delivery and latency metrics](/platform-api/webhooks/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/webhooks/delete-a-webhook.md) - [Update a webhook](/platform-api/webhooks/update-a-webhook.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.