Alert feed and webhooks

Every alert rule you own produces events: one per transfer, fill, liquidation, index crossing or liquidation-risk crossing it matched. An event is sent to the rule's channels and is also kept for 3 days in a feed you can read, over REST at GET /v1/alerts/events or over MCP with alerts_events. Rules are made with the MCP tools or under Account → Alerts; what each rule type watches is on Alerts. This page is the contract for what comes back: the feed route, the webhook body and the shape of each event.

Endpoint

GET https://data.vike.io/v1/alerts/events

GET https://data.vike.io/v1/alerts/events

Send the same X-API-Key header as every other /v1 route (Authentication). The answer is always about the key's own account: there is no parameter that names another user, and a rule_id that belongs to someone else gives an empty page. A call costs 1 credit and counts against the hourly and per-minute limits like any other /v1 call (Rate limits); a call that is answered with an error costs nothing.

The answer

{
  "events": [
    {
      "id": 1042,
      "rule_id": 77,
      "alert_label": "Whale BTC fills",
      "alert_type": "hl_wallet",
      "created_at": "2026-10-28T09:14:41.200Z",
      "event": {
        "schema": "vike.event.v1",
        "event_id": "hl.fills:0x1111111111111111111111111111111111111111:1793178870482:123456789",
        "source": "hl.fills",
        "kind": "fill",
        "ts": "2026-10-28T09:14:30.482Z",
        "cursor": "1793178870482-00000000000123456789",
        "chain": "hyperliquid",
        "subject": { "wallet": "0x1111111111111111111111111111111111111111", "symbol": "BTC" },
        "data": {
          "action": "open", "side": "buy", "size_usd": 1250000.0, "size_token": 12.5, "price": 100000.0,
          "closed_pnl": 0.0, "start_position": 0.0, "position_after": 12.5, "crossed": true,
          "trade_id": 123456789, "dex": "HL"
        },
        "labels": { "pnl_cohort": "2x smart", "pnl_cohort_basis": "live", "pnl_cum_usd": 4210000.0, "size_cohort": "3x whale" }
      },
      "delivery": [ { "channel": "webhook", "channel_key": "12", "status": "sent" } ]
    }
  ],
  "next_cursor": "eyJpZCI6MTA0Mn0",
  "has_more": false
}

This example shows the shape; its values are made up. The wallet, ids and prices are not a real capture.

Each element of events is one event of one rule:

A delivery's status is pending (not tried yet), retry (a try failed, another is scheduled), sent, expired (not delivered within 72 hours), skipped (the channel was deleted, disabled or changed before the send) or unsupported (the channel cannot carry this event). It is read when you ask, so it moves on between polls.

Paging

• Events come oldest first, so a poller walks forward: pass next_cursor back as cursor.
• A page shorter than limit with has_more: false means you have caught up. Poll again later with the same next_cursor; an empty page returns it unchanged.
• An event is in the feed as soon as it is recorded, which is before its email or webhook is sent. Events appear in the order they are numbered, so a poller that always passes back the last next_cursor misses none and sees none twice.
• Events are kept 3 days. A cursor older than that does not fail: the feed continues from the oldest event still kept.
• Deleting a rule for good (alerts_delete with hard: true) removes its events. Pausing it keeps them.
• Only events of your own rules appear.

Errors

The webhook body

A webhook channel receives the same event as a POST. Every rule type uses one envelope; the signature and the retries are on alerts_register_webhook.

{
  "schema": "vike.alert.v1",
  "alert_id": 77,
  "alert_label": "Whale BTC fills",
  "alert_type": "hl_wallet",
  "triggered_at": "2026-10-28T09:14:30.482000+00:00",
  "event": { "schema": "vike.event.v1", "event_id": "hl.fills:0x1111111111111111111111111111111111111111:1793178870482:123456789", "...": "as in the feed" }
}

For a transfer event the body also carries the flat keys the earlier webhook format had, so a receiver written for it keeps working: chain, token (the symbol, empty when the token has none), value_usd (null when the transfer has no USD value), from_address, to_address and tx_hash. Those three are bare lowercase hex without 0x; inside event the same values keep their 0x.

Two request headers identify the event: X-Vike-Event-Id (the event's event_id) and X-Vike-Attempt (1 for the first try, then 2, 3 and so on). Delivery is at least once: a send that was cut off can arrive twice, so dedupe on event_id.

Event shapes

Every event, in the feed or in a webhook, has the same ten fields, and kind says which data and subject to expect.

Two things to know when you parse them. A fill's trade_id can be larger than 2^53, which JavaScript reads inexactly: take the exact value from event_id (it ends with the id). And a liquidation is inferred from changes between position captures, so its time is the minute it was found, not the instant of the liquidation; see how soon an alert arrives.

Ask your agent

Connected to the Vike MCP server (https://data.vike.io/mcp) in Claude, ChatGPT or Cursor, ask it in plain words. The alerts_events tool reads this feed, at 1 credit a call.

What have my alerts fired since yesterday?