Home>Blog>Build a Hyperliquid Webhook Alert System in 30 Minutes
Build a Hyperliquid Webhook Alert System in 30 Minutes

Build a Hyperliquid Webhook Alert System in 30 Minutes

By @CoinMarketMan - 10-Jul-2026

在30分钟内构建 Hyperliquid Webhook 告警系统

你的轮询循环每五分钟触发一次,拉取相同的 cohort 数据,与上次快照对比,然后判断没有变化。与此同时,Money Printer cohort 刚刚在 ETH 上翻转为净空头,$3,800 价位附近形成了清算集群,三条 Leviathan 在 SOL 上开了新多头。等你下次轮询到达时,行情早已被消化。

轮询是默认方案,因为它是最简单的模式。你设置一个间隔,请求端点,对比响应差异,然后收工。但简单的代价是延迟、在未变动数据上浪费 API 调用,以及那种总觉得在最近两次请求之间错过了什么重要信号的不安感。Webhook 颠覆了这个模型。与其每隔几分钟问"有什么变化吗?",服务器会在事情发生的那一刻主动告诉你。

HyperTracker 的 webhook 推送功能在 Flow($799/月)和 Stream($1,999/月)套餐中提供。 你注册一个 URL,配置你关心的事件类型,我们的基础设施会在数据刷新周期检测到事件的瞬间,将一个签名的 JSON 载荷推送到你的端点。 不需要 cron 任务,不需要计算速率限制,也没有数据过期窗口。本指南将完整介绍整套设置:接收 webhook、验证载荷、将告警路由到 Telegram 或 Discord,以及优雅地处理失败。

Polling Vs Webhook Architecture

轮询与推送:你究竟在损失什么

轮询的代价不仅仅是延迟。来看一个典型集成的计算。如果你每五分钟轮询一次 cohort 指标端点,每天就是 288 次请求,每月约 8,640 次,这还只是单个端点、单个资产。加上五种资产就到了 43,200 次。再加上订单流快照和清算风险,仅监控一项就能耗尽 Pulse 套餐每月 50,000 次的请求配额, 用于按需查询的预算为零。

Webhook 彻底消除了这个问题。你只订阅你关心的事件,只有在真正发生变化时才会触发请求。市场平静的时候不花你一分成本。行情剧烈的一天会发来一批载荷,但每一条都携带可操作的信息,而不是你不得不处理后再丢掉的"无变化"响应。

延迟差距同样重要。五分钟轮询的最坏情况下,检测延迟接近五分钟,而且即使什么都没变你也要承担所有请求开销。使用 webhook,我们系统在刷新周期检测到事件的瞬间你就收到载荷,中间没有任何无效调用。对于 cohort 转变和清算爆仓,消除轮询开销、获得即时推送,意味着更简洁的架构和更快的反应链路。

搭建你的 webhook 端点

接收器只是一个接受 POST 请求、验证载荷并快速返回 200 状态码的 HTTP 服务器。你的端点应在几秒内响应,以避免触发重试逻辑。如果推送失败,会以指数退避的方式重试。持续失败将暂停 webhook,直到你在控制台重新启用。

以下是一个使用 Express 的最简 Node.js 接收器:

import express from 'express';
import crypto from 'crypto';

const app = express();
app.use(express.json());

const WEBHOOK_SECRET = process.env.HT_WEBHOOK_SECRET;

function verifySignature(payload, signature) {
  const expected = crypto
    .createHmac('sha256', WEBHOOK_SECRET)
    .update(JSON.stringify(payload))
    .digest('hex');
  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(expected)
  );
}

app.post('/webhooks/hypertracker', (req, res) => {
  const signature = req.headers['x-ht-signature'];

  if (!signature || !verifySignature(req.body, signature)) {
    console.error('Invalid webhook signature');
    return res.status(401).json({ error: 'Invalid signature' });
  }

  // Acknowledge immediately, process async
  res.status(200).json({ received: true });

  // Handle the event
  processEvent(req.body);
});

app.listen(3000, () => console.log('Webhook receiver on :3000'));

有三点需要注意。第一,签名验证不是可选项。没有它,任何发现你端点 URL 的人都可以发送伪造的载荷。HMAC-SHA256 校验确认载荷来源于 HyperTracker。第二,先确认再处理。立即发送 200,然后异步处理业务逻辑。如果你的告警路由遇到缓慢的下游服务(Telegram API 抖动、数据库写入),你不希望 webhook 推送因为等待而超时并触发重试。第三,比较时使用 timingSafeEqual 以防止针对签名的计时攻击。

暴露你的本地服务器

开发阶段,你的 localhost 无法从公网访问。使用隧道将其暴露出来:

# Option 1: ngrok
ngrok http 3000

# Option 2: Cloudflare Tunnel
cloudflared tunnel --url http://localhost:3000

复制生成的 HTTPS URL,粘贴到 HyperTracker 的 webhook 配置中。生产环境中,部署到任何能提供稳定 HTTPS 端点的云服务商。一台 $5/月的 VPS 足以运行 webhook 接收器。

Webhook Event Flow

选择要订阅的事件

不是每个事件都值得触发告警。毁掉一个通知频道最快的方法就是让噪音淹没它,直到你开始忽略所有消息。从一组信噪比高的核心事件入手,等摸清流量后再扩展。

监控 Hyperliquid 的交易者实用初始配置:

| 事件类型 | 触发条件 | 重要性 | | --- | --- | --- | | cohort.shift | 某个 PnL cohort 在某资产上翻转净多/净空 | Money Printer 或 Smart Money 的反转是高确信度信号 | | liquidation.cluster | 清算风险评分超过阈值 | 集群区域吸引价格,在剧烈波动时尤为明显 | | position.large | 超过名义金额阈值的仓位被开启或关闭 | Whale 进出场会在 Hyperliquid 上撬动市场 | | order_flow.spike | 5 分钟窗口内订单流量超过 z-score 阈值 | 突发流量涌现往往预示方向性行情 |

你可以在 HyperTracker 控制台的 Settings > Webhooks 中配置这些事件,也可以通过 webhook 管理端点以编程方式配置。每种事件类型支持可选过滤器:资产代号、cohort ID、最小名义金额和阈值。在源头过滤始终优于在接收器中过滤,因为这样能降低载荷量,让你的处理逻辑保持简洁。

将告警路由到 Telegram

Telegram 是加密交易者的默认通知频道,因为它速度快、支持富文本格式,并可在所有设备上运行。路由函数获取已验证的 webhook 载荷,并向你的 Telegram 聊天或群组发送格式化消息。

async function sendTelegramAlert(event) {
  const TELEGRAM_TOKEN = process.env.TELEGRAM_BOT_TOKEN;
  const CHAT_ID = process.env.TELEGRAM_CHAT_ID;

  const message = formatMessage(event);

  await fetch(
    `https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage`,
    {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        chat_id: CHAT_ID,
        text: message,
        parse_mode: 'HTML',
      }),
    }
  );
}

function formatMessage(event) {
  switch (event.type) {
    case 'cohort.shift':
      return [
        `<b>Cohort Shift: ${event.data.asset}</b>`,
        `${event.data.cohort_name} flipped <b>${event.data.direction}</b>`,
        `Net position: ${event.data.net_position.toFixed(2)}`,
        `Time: ${new Date(event.timestamp).toUTCString()}`,
      ].join('\n');

    case 'liquidation.cluster':
      return [
        `<b>Liquidation Cluster: ${event.data.asset}</b>`,
        `Risk score: ${event.data.risk_score}/100`,
        `Price zone: $${event.data.price_low} - $${event.data.price_high}`,
        `Estimated exposure: $${(event.data.notional / 1e6).toFixed(1)}M`,
      ].join('\n');

    default:
      return `<b>${event.type}</b>\n${JSON.stringify(event.data, null, 2)}`;
  }
}

创建 Telegram 机器人:在 Telegram 上给 @BotFather 发消息,执行 /newbot,保存 token。将机器人添加到你的告警频道或群组,然后从 getUpdates 端点获取 chat ID。整个过程大约两分钟。

Discord 替代方案

如果你的团队使用 Discord,webhook 推送更为简单。Discord 频道内置 webhook URL,无需管理机器人 token:

async function sendDiscordAlert(event) {
  const DISCORD_WEBHOOK_URL = process.env.DISCORD_WEBHOOK_URL;

  await fetch(DISCORD_WEBHOOK_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      embeds: [{
        title: `${event.type}: ${event.data.asset}`,
        description: formatMessage(event),
        color: event.data.direction === 'long' ? 0x22c55e : 0xef4444,
        timestamp: event.timestamp,
      }],
    }),
  });
}

Alert Routing Channels

processEvent 路由器

接收器和推送渠道搭建完毕后,路由器将它们串联起来。这里你决定哪些事件去往哪里,应用本地过滤逻辑,并添加持久化日志以便调试。

async function processEvent(event) {
  // Log every event for debugging and replay
  console.log(JSON.stringify({ ts: Date.now(), event }));

  // Route by event type and severity
  switch (event.type) {
    case 'cohort.shift':
      // Only alert on the high-conviction cohorts
      const alertCohorts = [
        'Money Printer', 'Smart Money', 'Leviathan', 'Tidal Whale'
      ];
      if (alertCohorts.includes(event.data.cohort_name)) {
        await sendTelegramAlert(event);
        await sendDiscordAlert(event);
      }
      break;

    case 'liquidation.cluster':
      // Adjust threshold to your risk tolerance
      if (event.data.risk_score > 75) {
        await sendTelegramAlert(event);
      }
      break;

    case 'position.large':
      await sendTelegramAlert(event);
      break;

    case 'order_flow.spike':
      // Example: z > 3 catches extreme spikes. Tune for your strategy.
      if (event.data.z_score > 3) {
        await sendTelegramAlert(event);
      }
      break;

    default:
      console.log('Unhandled event type:', event.type);
  }
}

注意过滤层。cohort.shift 处理器只对 Money Printer、Smart Money、Leviathan 和 Tidal Whale 触发告警。这些 cohort 的方向性转变信号最强:累计盈利超过 $1M 的钱包(Money Printer)、$100K 到 $1M(Smart Money),以及最大账户规模($1M 到 $5M 的 Tidal Whale,$5M+ 的 Leviathan)。 Shrimp 或 Fish cohort 的转变并非毫无意义,但它会在一个你需要保持信任的通知频道里制造过多噪音。

在不丢失事件的前提下处理失败

分布式系统会出故障。你的服务器因部署而宕机。Telegram 在剧烈行情的一小时内对你限速。Discord 有三十秒返回 502。如果你的告警管道不能处理这些失败,你就会错过最关键的事件:那些在混乱中触发的事件。

两种配合使用效果很好的模式:

1. 本地重试队列

当推送渠道失败时,将事件推入重试队列而不是直接丢弃。对于低流量场景,一个简单的内存数组就够用。生产环境建议使用 Redis 或持久化队列:

const retryQueue = [];

async function safeDeliver(deliverFn, event, channel) {
  try {
    await deliverFn(event);
  } catch (err) {
    console.error(`Delivery failed (${channel}):`, err.message);
    retryQueue.push({ deliverFn, event, channel, attempts: 1 });
  }
}

// Process retries every 30 seconds
setInterval(async () => {
  const batch = retryQueue.splice(0, 10);
  for (const item of batch) {
    try {
      await item.deliverFn(item.event);
    } catch {
      item.attempts++;
      if (item.attempts < 5) retryQueue.push(item);
      else console.error('Dropped after 5 retries:', item.event.type);
    }
  }
}, 30_000);

2. 事件日志用于重放

在路由之前,将每个传入的 webhook 记录到文件或数据库。如果你发现格式化逻辑存在 bug 或漏掉了某个推送渠道,可以重放日志来补发告警。上面 processEvent 中的 JSON 日志行就是最简单的实现。生产环境中,追加写入文件或写入 SQLite 表。

测试你的 webhook 管道

在依赖真实市场事件之前,用合成载荷端到端验证你的管道。向本地端点发送一个具有真实载荷结构的测试 POST:

curl -X POST http://localhost:3000/webhooks/hypertracker \
  -H "Content-Type: application/json" \
  -H "x-ht-signature: test-skip-in-dev" \
  -d '{
    "event_id": "test-001",
    "type": "cohort.shift",
    "timestamp": "2026-07-10T14:30:00Z",
    "data": {
      "asset": "ETH",
      "cohort_name": "Money Printer",
      "cohort_id": 8,
      "direction": "short",
      "net_position": -1247.5
    }
  }'

检查你的 Telegram 频道或 Discord 服务器是否收到了格式化告警。然后测试失败路径:临时撤销你的 Telegram 机器人 token,再发送一个测试事件,确认它进入了重试队列。这两项检查——正常路径和失败路径——能在上线前发现大多数集成问题。

HyperTracker 控制台的 webhook 配置页面也提供"发送测试事件"按钮。它通过生产推送管道发送一个真实载荷结构,让你可以在不等待市场事件的情况下验证端点是否可达且响应正常。

从告警到自动化

告警管道运行起来后,下一步自然是以编程方式响应这些信号。路由到 Telegram 的同一个 processEvent 函数也可以触发交易、调整仓位或更新看板。Money Printer 净空头 BTC 的 cohort 转变,可以自动收紧你的止损。当前价格上方形成清算集群,可以触发对冲操作。

这个架构能扩展,正是因为 webhook 将检测与响应解耦。你的接收器处理"发生了什么"这一层。独立模块处理"我们要怎么做"这一层。你可以在不改动接收器或签名验证的情况下添加新动作(推送到 Slack、记录到数据库、触发 TradingView 告警)。

HyperTracker 将 Hyperliquid 上的每个钱包划分为 16 个行为 cohort:8 个按账户规模(Shrimp 到 Leviathan),8 个按历史总 PnL(Money Printer 到 Giga-Rekt)。 当这些分类在聚合层面发生转变时,webhook 触发。你的工作是判断这次转变对你的仓位意味着什么,并将响应逻辑接入系统。

开始用 webhook 构建

Webhook 推送功能在 HyperTracker 的 Flow($799/月)和 Stream($1,999/月)套餐中提供。 Flow 提供 webhook 加每月 400,000 次 API 请求和 200 次/分钟的速率限制。Stream 增加 WebSocket 推送、每月 200 万次请求和 500 次/分钟。两个套餐均包含完整的 cohort 分析、订单流和清算风险端点,这些端点为本指南中展示的告警事件提供数据支持。

探索 HyperTracker API 套餐

大多数交易基础设施从轮询循环起步,因为教程里都是这么写的。能做出生产级系统的构建者,会尽早迁移到推送模式,因为信号检测每多一分钟延迟,都会累积成错过的交易机会和过期的告警。现在花三十分钟完成设置,换来的是不必在凌晨三点市场剧烈波动时调试一个时不时出问题的 cron 任务。