简介
通常,当您向 API 端点发出请求时,您期望获得近乎即时的响应。但是,某些请求可能需要较长时间处理,这可能导致超时错误。为了防止超时错误,会返回一个待处理响应。由于您的记录需要更新为请求的最终状态,您需要:- 请求更新(通常称为轮询),或
- 使用 Webhook URL 监听事件。
轮询 vs Webhooks
轮询需要定期发出GET 请求以获取请求的最终状态。例如,当您为客户分配充值地址时,您需要不断请求与该地址关联的交易,直到找到一个。
使用 Webhooks,资源服务器(在本例中为 Blockradar)会在您请求的状态发生变化时向您的服务器发送更新。请求状态的变化称为事件。您通常会在称为 Webhook URL 的 POST 端点上监听这些事件。
下表突出显示了轮询和 Webhooks 之间的一些差异:
| 轮询 | Webhooks | |
|---|---|---|
| 更新方式 | 手动 | 自动 |
| 速率限制 | 是 | 否 |
| 受扩展影响 | 是 | 否 |
创建 Webhook URL
Webhook URL 只是资源服务器发送更新的 POST 端点。该 URL 需要解析 JSON 请求并返回200 OK:
200 OK。如果响应头中没有 200 OK,我们将在接下来的 2 小时 35 分钟内持续发送事件:
- 我们将尝试发送 5 次 Webhook,每次尝试之间的延迟递增,从 5 分钟开始并以指数方式增加到 80 分钟。这 5 次尝试的总持续时间约为 2 小时 35 分钟。
本地测试 Webhooks
在开发过程中,您可以在测试主钱包环境中将 Webhook URL 配置为本地地址,例如http://localhost 或 127.0.0.1。
要将本地服务器暴露到互联网以进行测试,请考虑使用 ngrok 或 webhook.site 等工具。这些工具允许您查看 Webhook 载荷的样子,并在将应用程序部署到正式环境之前在本地模拟 Webhook 事件。
使用这些工具,您可以确保 Webhook 集成正常工作,并在进入生产环境之前在受控的本地环境中处理任何问题。
重新发送交易 Webhook
如果由于某些原因您没有收到交易 Webhook 且退避时间已过,我们提供了一个 API 供您重新发送交易 Webhook验证事件来源
由于您的 Webhook URL 是公开可用的,您需要验证事件是否来自 Blockradar 而不是恶意攻击者。有两种方法可以确保 Webhook URL 的事件来自 Blockradar:- 签名验证(推荐)
签名验证
从 Blockradar 发送的事件带有 x-blockradar-signature 头。此头的值是使用您的密钥对事件载荷进行 HMAC SHA512 签名的结果。应在处理事件之前验证头签名:上线检查清单
现在您已成功创建 Webhook URL,以下是确保您获得良好体验的一些方法:- 在 Blockradar 控制面板的主钱包上添加 Webhook URL
- 确保您的 Webhook URL 是公开可用的(localhost URL 无法接收事件)
- 如果使用
.htaccess,请记住在 URL 末尾添加尾部/ - 测试您的 Webhook 以确保您获取 JSON 主体并返回
200 OKHTTP 响应 - 如果您的 Webhook 函数有长时间运行的任务,您应该首先通过返回
200 OK确认收到 Webhook,然后再继续长时间运行的任务 - 如果我们没有从您的 Webhook 收到
200 OKHTTP 响应,我们会将其标记为失败尝试 - 我们将尝试发送 5 次 Webhook,每次尝试之间的延迟递增,从 5 分钟开始并以指数方式增加到 80 分钟。这 5 次尝试的总持续时间约为 2 小时 35 分钟。
事件类型
以下是我们目前触发的事件。随着我们在未来接入更多操作,我们会将更多事件添加到此列表中。事件示例
以下是一些最常见事件的 Webhook 载荷示例:- 充值成功
- 充值处理中
- 提现成功
- 交换成功
- 充值归集成功
- 提现失败
祝您开发愉快!

