Skip to main content
Account events (account.*) report on wallets you register once, on your list of watched addresses. Any address may be watched: your own accounts, or counterparties you follow. Once an address is on the list, every account.* rule you hold reports on it, subject to that rule’s own configuration. Addresses you have not registered never produce account events, whatever a rule says.
  • account.fill: executions, one event per venue, market, block and account.
  • account.liquidated: liquidations.
  • account.transfer: HyperCore spot token movements in or out.
  • account.twap_lifecycle: TWAP state changes.
  • account.order_rejected: orders the engine cancelled without the account asking.
  • account.hip4_settled: HIP-4 position settlements.
Events has the venues, latency and parameters of each. How many addresses you can watch at once is set by your plan; see Limits and plans.

​
Add, list and remove addresses

  • List: GET /v1/webhooks/addresses, or the MCP tool list_webhook_watched_addresses.
  • Add: POST /v1/webhooks/addresses, or add_webhook_watched_address.
  • Remove: DELETE /v1/webhooks/addresses/{id}, or delete_webhook_watched_address.
In the dashboard, the same list is the Watched wallets tab under Webhooks. The request body is {"address": "...", "label": "..."}. label is optional and is truncated to 64 characters. The address must be a 0x-prefixed, 40-hex-character EVM address. It is lowercased before it is stored, so casing and surrounding whitespace do not matter. Anything else returns a 400.
limit is your plan’s address allowance; the list response carries it too. Adding an address you already watch returns the existing row, updates its label, and does not count against the allowance. A new address beyond the allowance returns a 400 that names it. List and remove return the same row shape. Hyperliquid’s bridge system addresses are refused: 0x2222...2222 and the 0x2000... family that ends in a token index are the counterparty to every Core-to-EVM move of their token, not accounts. The 400 says so. Watch the account on your side of the bridge instead.

​
Narrow a rule to some of your addresses

Create a rule for an account.* type the same way as for any other event. A rule with no addresses reports on every address you watch. To narrow it, list a subset in addresses; each one must already be on your watched list, or the create is refused with a 400 that says to add it first.
The rule’s own configuration narrows venue, symbols, size and the other declared metrics; the watched list decides which addresses count. Rules covers the configuration. An account.* estimate or dry-run needs at least one watched address. With none, it returns a 400 asking you to add one first, or, on a plan that cannot hold watched addresses, saying which plan can. Estimate and dry-run lists which account events can be previewed at all.

​
Example: a wallet you follow is liquidated

One conversation with an agent covers the whole job: pick an event, size it, point it somewhere, confirm it arrived. The same steps work in the dashboard or over REST. You: Tell me when a wallet I follow is liquidated on Hyperliquid for more than a quarter of a million dollars.
  1. It reads the catalog. list_webhook_event_types returns one declaration per event type: scope, venues, the filters each accepts, the params that define an occurrence, the metrics a condition can test and the operator vocabulary. Every rule is checked against that declaration, so this is what the agent works from rather than guessing field names. Here it lands on account.liquidated, whose scope is addresses.
  2. It checks what your plan allows. get_webhook_limits returns your plan, whether webhook delivery is included, and what you have used against each allowance. On a plan without delivery it says so in a sentence you can read, along with the plan that would include it.
  3. It registers the wallet. add_webhook_watched_address puts the address on your watched list. account.* events are detected only for watched addresses, so this comes before the rule.
  4. It sizes the rule before you own it. estimate_webhook_subscription replays the configuration over recent history and answers the question a threshold cannot answer on its own: how often would this fire? You get a per-day rate, the typical day and the worst day, and a ladder of thresholds with the rate each one would have produced. account.liquidated has no dry-run yet, so here the estimate and its ladder are the whole sizing step.
  5. It creates the endpoint and the rule. create_webhook_endpoint registers your HTTPS URL and returns the signing secret once, so store it then. create_webhook_subscription points the endpoint at account.liquidated with a notional_usd condition at 250,000 and echoes back the stored configuration with defaults filled in.
  6. It confirms a delivery arrives. test_webhook_endpoint queues a real signed webhook.test, and list_webhook_deliveries reads the outcome: state, attempts, the status code your receiver returned and the error if it was not a 2xx.

​
Next step

Size a rule for your addresses

See how often an account rule would have fired for the addresses you watch, then create it.
Last modified on October 6, 2026