> ## Documentation Index > Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt > Use this file to discover all available pages before exploring further. # Watched addresses > Register the wallets whose fills, liquidations, transfers, TWAPs, forced cancels and HIP-4 settlements your account.* rules report on. 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](/webhooks/events#account-scoped) 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](/webhooks/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. ```bash theme={"theme":"github-dark"} curl -X POST https://api.0xarchive.io/v1/webhooks/addresses \ -H "X-API-Key: $OXARCHIVE_API_KEY" \ -H "content-type: application/json" \ -d '{"address": "0xAbC0000000000000000000000000000000000001", "label": "desk A"}' ``` ```json theme={"theme":"github-dark"} { "success": true, "data": { "id": "6b1d2c4e-1f0a-4c8e-9a2b-3d4e5f607182", "address": "0xabc0000000000000000000000000000000000001", "label": "desk A", "created_at": "2026-09-09T12:00:00Z" }, "limit": 15 } ``` `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. ```json theme={"theme":"github-dark"} { "endpoint_id": "f4797c46-ada6-4c09-a076-5689a974e4be", "event_type": "account.fill", "filters": { "addresses": ["0xabc0000000000000000000000000000000000001"], "conditions": [{ "metric": "notional_usd", "op": "greater_than_or_equal", "value": 25000 }] } } ``` The rule's own configuration narrows venue, symbols, size and the other declared metrics; the watched list decides which addresses count. [Rules](/webhooks/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](/webhooks/estimate-and-dry-run#which-event-types-can-be-previewed) 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 See how often an account rule would have fired for the addresses you watch, then create it. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.