把短网址点击事件经 Webhook 推送给外部系统, 可自动写入 CRM、 Slack 即时告警、 Google Sheets 汇总、社内 BI 工具。一日数十万次点击规模时, CSV 导出加手工导入难以维持, Webhook 实时整合事实上必需。 Bitly、 Rebrandly、 Short.io 等主要服务均提供 Webhook 整合, 在 SaaS 行业已是标准。
Webhook 设计先定 payload schema: 点击事件应含短代码、原 URL、点击时间 (UTC)、 IP、 User-Agent、 Referer、地理 (国家、地区)、设备类型、 UTM 参数。用 JSON Schema 严格定义, 追加字段放 「extensions」 子对象保持向后兼容, Stripe 与 GitHub Webhook 是良好范例。
签名校验是 Webhook 安全核心: 发送方用 HMAC-SHA256 对 payload 签名, 接收方用同密钥校验。 GitHub Webhook 的 「X-Hub-Signature-256」 头与 Stripe 的 「Stripe-Signature」 头是标准实现。无签名仅 IP 白名单, 攻击者仍可注入任意 payload。配合时间戳校验 (5 分钟内) 可防重放攻击。要学习 API 整合, 相关书籍可在 Amazon 找到。
幂等性常被忽略却很关键: 网络错误重发会重复处理。给每次 Webhook 一个唯一 「event_id」, 接收方在过去 24 小时已处理则忽略。 Redis 或 DynamoDB TTL 可自动过期。重发逻辑常见为指数退避 (1m、 5m、 30m、 2h、 8h) 最多 5 次, 4xx 立即停, 5xx 与超时再退避。接收端应在 1 秒内回 200, 重活异步排队 (SQS、 Pub/Sub)。