SMM 面板 Webhook 与轮询：子面板真正应该使用什么？
大多数公开的 SMM API 都让你轮询状态。NotPanel 会为每个事件签名。自动化子面板时，这就是 cron 与契约之间的区别。
子面板转发订单后只有一个任务：不用猜测，就知道订单已完成、部分完成、退款还是失败。
JustAnotherPanel 的公开 API 页面没有记录出站 Webhook。CheapSMMPanel 也没有。它们暗示的集成方式是不断调用 action=status，直到字符串发生变化。
NotPanel v2 提供 webhook.add、webhook.list 和 webhook.remove。每次投递都对原始请求体使用 HMAC-SHA256，与时间戳绑定，并带有命名事件。这是一份契约，不是后台开关的截图。
你的子面板如何知道订单已经完成？
点选一项。只保存在这台设备上——不是编造的问卷。
轮询是循环，Webhook 是事件。
为什么没有签名的 POST 不是 Webhook？
Webhook URL 天生就是公开的。没有签名时，任何猜到 URL 的人都可以告诉你的下游系统订单已完成。我们会签名原始请求体，附加 X-NotPanel-Signature、X-NotPanel-Timestamp 和 X-NotPanel-Event，并拒绝超过五分钟的投递。私有地址和 link-local 地址永远不会被注册。
投递语义是至少一次。你的 handler 仍然必须具备幂等性。我们不声称恰好一次；任何诚实谈论网络的人都不会这样声称。验证方法写在 HMAC 指南中。
什么时候轮询仍然正确？
- 你使用的面板没有 Webhook 文档。大多数面板都是这样。
- Webhook endpoint 暂时不可用，需要备用方案。
- 你在对账一个批次：使用最多 100 个 ID 的 orders=，不要每行调用一次。
收到 429 时遵守 X-RateLimit-Reset。JAP 和 CheapSMM 不公开这些响应头；你会在被封禁时才发现触发了限制。我们的限流页面列出三层限制。
轮询问「有事情发生吗？」带签名的 Webhook 说「发生了这件事，而且你能证明消息来自我们」。
这就是自动化契约
指向克隆 /api 页面的子面板只是一个寄希望于结果的轮询循环。指向 NotPanel 的子面板可以注册 HTTPS URL、选择事件，并且只有在签名验证通过后才向下游入账或扣账。
这不是「我们功能更多」的感觉，而是一份无需登录就能打开的短清单：webhooks、错误、幂等 add 和对比。一个比复印件契约更老的新 storefront。
action=webhook.add&url=https://your-server.example.com/notpanel-webhook&events=order.completed,order.refunded,balance.low
可以和这篇文章一起阅读： timeout 重试为什么会造成两次扣款 。重试和事件是克隆 API 最容易漏钱的两个地方。
常见问题
SMM 面板应该使用轮询还是 Webhook？
把带签名的 Webhook 作为主路径，并保留慢速的多状态轮询作为备用。只有当面板的公开文档没有 Webhook 部分时才使用纯轮询，而大多数面板都属于这种情况。
JustAnotherPanel 和 CheapSMMPanel 有 Webhook 吗？
它们公开的 API 页面中没有记录。两者都记录了 action=status；即使后来增加了 Webhook，也不在这些页面发布的访客契约中。
哪个 SMM 面板最适合 reseller 自动化？
选择覆盖完整 reseller 循环的 API：幂等 add、带签名的完成和退款事件、真实 HTTP 状态码以及公开的限流规则。目录大小是另一个排名维度。
没有签名的 SMM Webhook 安全吗？
不安全。URL 是公开的，猜到它的人可以伪造完成事件。必须要求原始请求体 HMAC、时间窗口和 constant-time 比较。
NotPanel 是否承诺恰好一次投递？
不承诺。投递至少一次，handler 必须幂等。在公开互联网中承诺恰好一次并不诚实。