Webhook 与通知
跟踪订单很简单：随时调用 GET /order/{id} 即可获取它的当前状态——大多数集成只需这样就够了。
Webhook 是可选的。 如果你不想轮询，TRONAgg 可以在订单变化的那一刻主动推送一条带签名的 JSON 事件给你，你在收到时更新自己的记录即可。只有当你更偏好推送而非轮询时，才需要配置它。
轮询 GET /order/{id} 效果很好，且无需任何配置。Webhook 只是一种便利，适合你更想被推送而非主动轮询的场景。
渠道
通知通过以下两种渠道之一送达，两者的事件与偏好设置完全一致：
- Webhook——向你的后端发送带签名的 JSON
POST。面向开发者与自动化。 - Telegram——在 Telegram 会话中收到可读的提醒。无需代码。
配置 Webhook
Webhook 有两种创建方式。
创建 Webhook 前，账户的累计确认充值必须超过 1 TRX。此限制按历史累计充值计算；购买后当前余额低于 1 TRX 不影响创建。
在 Workspace 中（无需代码）：
- 打开 Workspace → Notifications → Delivery methods → Webhook → Connect。
- 填写名称和一个返回
2xx的 HTTPS URL。 - 复制签名密钥（signing secret）——它只显示一次。请作为服务端密钥保存，验证每次投递都需要它。
- 在 Notifications 标签页选择哪些事件发往该 Webhook。用 Send test 发送一条示例投递，用 Delivery history 查看最近的尝试记录。
通过 API——用你的 API key 调用 POST /webhooks。签名密钥在响应中仅返回一次，请立即保存。以这种方式创建的 Webhook 默认启用订单跟踪（order.status_changed）——大多数集成想要的事件——其余事件则沿用同样的按事件默认值，你可以在 workspace 中调整。用 GET /webhooks、DELETE /webhooks/{id} 和 POST /webhooks/{id}/test 管理 Webhook。
你会收到什么
每次投递都是一个带签名的 JSON POST，携带单个事件：一个信封（id、type、created_at、data）加上带签名的请求头。在信任任何投递之前，务必先验证签名，并按事件 id 去重——投递为至少一次。
Webhook 事件 参考页是完整目录：投递信封与请求头、签名验证方法、每个事件及其示例载荷，以及哪些事件默认开启。大多数集成最想要的是 order.status_changed——它是轮询 GET /order/{id} 的推送替代方案。
下一步
- Webhook 事件——完整的事件目录、信封与签名验证。
- 跟踪订单状态——轮询端点，仍可用于按需查询。
- 代码示例——完整的购买 → 跟踪流程。