new_releases 更新:查看
版本说明,了解新功能和产品动态。
Webhook
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
网络钩子是合作伙伴指定的网址,RBM 平台会在该网址上发布消息和事件。此网址充当接收包含事件相关数据的 HTTPS POST 请求的端点。这意味着,系统会通过 HTTPS 安全地将数据发送到您的应用。
网络钩子网址可能如下所示:https://[your company name].com/api/rbm-events
。配置好网络钩子后,您就可以开始接收消息和事件了。
合作伙伴网络钩子和代理网络钩子
您可以在合作伙伴级别或代理级别配置网络钩子。
如果您同时配置了合作伙伴网络钩子和代理网络钩子,则代理网络钩子对其特定代理具有优先级,而合作伙伴网络钩子适用于没有自己网络钩子的任何代理。
您会在合作伙伴的 webhook 中收到发送给代理的消息。如果您希望特定代理的消息到达其他 webhook,请设置代理 webhook。
- 打开 Business Communications 开发者控制台,然后使用您的 RBM 合作伙伴 Google 账号登录。
- 点击您的代理。
- 点击集成。
- 对于网络钩子,点击配置。
- 在网络钩子端点网址部分,输入以“https://”开头的 webhook 网址。
- 记下您的
clientToken
值。您需要使用它来验证您收到的消息是否来自 Google。
将 webhook 配置为接受具有指定 clientToken
参数的 POST
请求,并发送包含 secret
参数的纯文本值作为响应正文的 200 OK
响应。
例如,如果您的 webhook 收到具有以下正文内容的 POST
请求
{
"clientToken":"SJENCPGJESMGUFPY",
"secret":"1234567890"
}
然后,您的 webhook 应确认 clientToken
值,如果 clientToken
正确无误,则返回 200 OK
响应,并将 1234567890
作为响应正文:
// clientToken from Configure
const myClientToken = "SJENCPGJESMGUFPY";
// Example endpoint
app.post("/rbm-webhook", (req, res) => {
const msg = req.body;
if (msg.clientToken === myClientToken) {
res.status(200).send(msg.secret);
return;
}
res.send(400);
});
在 Play 管理中心内,点击验证。RBM 验证您的 webhook 后,对话框将关闭。
验证收到的消息
由于 webhook 可以接收来自任何发件人的邮件,因此您应先验证 Google 是否发送了传入邮件,然后再处理邮件内容。
如需验证您收到的消息是否由 Google 发送,请按以下步骤操作:
- 提取邮件的
X-Goog-Signature
标头。这是消息正文载荷经过哈希处理且采用 base64 编码的副本。
- 对请求的
message.body
元素中的 RBM 载荷进行 Base-64 解码。
- 使用 webhook 的客户端令牌(您在设置 webhook 时指定的令牌)作为密钥,为 base-64 解码的消息载荷的字节创建 SHA512 HMAC,并对结果进行 base64 编码。
- 将
X-Goog-Signature
哈希与您创建的哈希进行比较。
Node.js
if ((requestBody.hasOwnProperty('message')) && (requestBody.message.hasOwnProperty('data'))) {
// Validate the received hash to ensure the message came from Google RBM
let userEventString = Buffer.from(requestBody.message.data, 'base64');
let hmac = crypto.createHmac('sha512', CLIENT_TOKEN);
let data = hmac.update(userEventString);
let genHash = data.digest('base64');
let headerHash = req.header('X-Goog-Signature');
if (headerHash === genHash) {
let userEvent = JSON.parse(userEventString);
console.log('userEventString: ' + userEventString);
handleMessage(userEvent);
} else {
console.log('hash mismatch - ignoring message');
}
}
res.sendStatus(200);
消息处理
如果通过 webhook 返回的不是 200 OK
,则会被视为传送失败。
开发者必须注意,以较高的速率发送消息会以较高的速率生成 webhook 通知,因此必须设计代码,确保其能够以预期的速率使用通知。开发者务必要考虑可能导致失败响应的情况,包括来自其网站容器的 500
响应、超时或上游失败。需要考虑的事项包括:
- 确保您的 DDoS 防护配置能够处理预期的 webhook 通知速率。
- 确保数据库连接池等资源不会耗尽,并产生超时或
500
响应。
开发者应确保以异步方式处理 RBM 事件,并且不会阻止该 webhook 返回 200 OK
。

请务必不要在 webhook 本身中处理 RBM 事件。处理过程中的任何错误或延迟都可能会影响 webhook 返回代码:

递送失败时的行为
当 RBM 从网络钩子调用收到 200 OK
以外的响应时,会使用退避和重试机制。RBM 会增加重试之间的等待时间,最长可达 600 秒。系统会继续重试 7 天,之后便会丢弃该邮件。
代理级 webhook 的影响
RBM 会将合作伙伴的消息加入一个队列。如果合作伙伴使用的是代理级 webhook,请务必注意,一个 webhook 的失败会影响向其他 webhook 传送内容。在消息失败的后退期内,系统会调用其他代理的 Webhook。不过,由于失败的消息会加入队列以进行重试,因此总体投放率会下降,其他代理也会受到影响。
开发者必须了解这种模式并相应地编写代码,尽可能接受消息并将其加入队列以进行处理,以最大限度地减少返回失败的可能性。
后续步骤
配置好网络钩子后,您的代理便可以从测试设备接收消息。发送消息以验证您的设置。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-04-03。
[null,null,["最后更新时间 (UTC):2025-04-03。"],[[["\u003cp\u003eA webhook is a URL where the RBM platform sends messages and events via HTTPS POST requests, serving as a secure endpoint for data delivery.\u003c/p\u003e\n"],["\u003cp\u003eYou can configure webhooks at either the partner level, affecting all agents, or at the individual agent level, allowing for distinct behaviors per agent, with agent-level webhooks taking priority.\u003c/p\u003e\n"],["\u003cp\u003eTo ensure message authenticity, it's essential to verify that incoming messages are from Google by comparing the \u003ccode\u003eX-Goog-Signature\u003c/code\u003e header with a generated hash using your webhook's client token.\u003c/p\u003e\n"],["\u003cp\u003eWebhooks should return a \u003ccode\u003e200 OK\u003c/code\u003e response to acknowledge receipt; any other response triggers a retry mechanism that increases the wait time up to 600 seconds and continues for 7 days before dropping the message.\u003c/p\u003e\n"],["\u003cp\u003eWhen implementing agent-level webhooks, be aware that the failure of one webhook can affect message delivery to other webhooks due to the backoff and retry mechanism, emphasizing the need to code for message acceptance and queuing.\u003c/p\u003e\n"]]],[],null,["# Webhooks\n\nA webhook is a partner-specified URL where the RBM platform posts\n[messages](/business-communications/rcs-business-messaging/guides/build/messages/receive)\nand [events](/business-communications/rcs-business-messaging/guides/build/events).\nThis URL acts as an endpoint that receives HTTPS POST requests containing data\nabout the events. This means that data is sent to your application securely over\nHTTPS.\n\nA webhook URL might look something like this:\n`https://[your company name].com/api/rbm-events`.\nOnce you configure your webhook, you can start receiving messages and events.\n\nPartner webhooks and agent webhooks\n-----------------------------------\n\nYou can configure your webhook either at the partner level or at the agent\nlevel.\n\n- Your partner webhook applies to every agent you maintain. If your agents have similar behavior, or if you only have one agent, use the [partner webhook](/business-communications/rcs-business-messaging/guides/get-started/partner-account#configure_your_partner_webhook).\n- Agent webhooks apply to individual agents. If you operate multiple agents with distinct behavior, you can [set a different webhook for each agent](/business-communications/rcs-business-messaging/guides/integrate/webhooks#configure_an_agent_webhook).\n\nIf you've configured both a partner webhook and an agent webhook, the agent\nwebhook takes precedence on its specific agent, while the partner webhook\napplies to any agents that don't have their own webhook.\n\nConfigure an agent webhook\n--------------------------\n\n| **Note:** To create a webhook integration using the RBM Management API, refer to the [Create a webhook integration](/business-communications/rcs-business-messaging/guides/management-api/webhooks#create_a_webhook_integration) documentation.\n\nYou receive messages sent to your agent at your partner webhook. If you want\nmessages for a specific agent to arrive at a different webhook instead, set an\nagent webhook.\n\n1. Open the [Business Communications Developer Console](https://business-communications.cloud.google.com/?utm_source=/business-communications/business-messages/guides/how-to/agents&utm_medium=devsite&utm_campaign=rcs-business-messaging) and sign in with your RBM partner Google Account.\n2. Click your agent.\n3. Click **Integrations**.\n4. For **Webhook** , click **Configure**.\n5. For **Webhook endpoint URL**, enter your webhook URL beginning with \"https://\".\n6. Note your `clientToken` value. You need it to [verify that messages you receive are coming from Google](/business-communications/rcs-business-messaging/guides/integrate/webhooks#verify_incoming_messages).\n7. Configure your webhook to accept a `POST` request with the specified\n `clientToken` parameter and send a `200 OK` response with the plain text value\n of the `secret` parameter as the response body.\n\n For example, if your webhook receives a `POST` request with the following\n body content \n\n {\n \"clientToken\":\"SJENCPGJESMGUFPY\",\n \"secret\":\"1234567890\"\n }\n\n then your webhook should confirm the `clientToken` value and, if\n `clientToken` is correct, return a `200 OK` response with `1234567890` as\n the response body: \n\n // clientToken from Configure\n const myClientToken = \"SJENCPGJESMGUFPY\";\n\n // Example endpoint\n app.post(\"/rbm-webhook\", (req, res) =\u003e {\n const msg = req.body;\n if (msg.clientToken === myClientToken) {\n res.status(200).send(msg.secret);\n return;\n }\n res.send(400);\n });\n\n8. In the Developer Console, click **Verify**. When RBM verifies your webhook,\n the dialog closes.\n\nVerify incoming messages\n------------------------\n\nBecause webhooks can receive messages from any senders, you should verify that\nGoogle sent incoming messages before processing message content.\n\nTo verify that Google sent a message you received, follow these steps:\n\n1. Extract the message's `X-Goog-Signature` header. This is a hashed, base64-encoded copy of the message body payload.\n2. Base-64-decode the RBM payload in the `message.body` element of the request.\n3. Using your webhook's client token (which you specified when you set up your webhook) as a key, create a SHA512 HMAC of the bytes of the base-64 decoded message payload and base64-encode the result.\n4. Compare the `X-Goog-Signature` hash with the hash you created.\n - If the hashes match, you've confirmed that Google sent the message.\n - If the hashes don't match, check your hashing process on a known-good\n message.\n\n If your hashing process is working correctly and you receive a\n message that you believe was fraudulently sent to you,\n [contact us](https://support.google.com/messages/contact/contact_us).\n\n### Node.js\n\n```javascript\n if ((requestBody.hasOwnProperty('message')) && (requestBody.message.hasOwnProperty('data'))) {\n // Validate the received hash to ensure the message came from Google RBM\n let userEventString = Buffer.from(requestBody.message.data, 'base64');\n let hmac = crypto.createHmac('sha512', CLIENT_TOKEN);\n let data = hmac.update(userEventString);\n let genHash = data.digest('base64');\n let headerHash = req.header('X-Goog-Signature');\n\n if (headerHash === genHash) {\n let userEvent = JSON.parse(userEventString);\n\n console.log('userEventString: ' + userEventString);\n handleMessage(userEvent);\n } else {\n console.log('hash mismatch - ignoring message');\n }\n }\n\n res.sendStatus(200);\n \n```\n\nMessage handling\n----------------\n\nReturning anything other than `200 OK` from a webhook is considered a delivery\nfailure.\n\nDevelopers must be mindful that sending messages at high rates will\ngenerate webhook notifications at high rates and must design their code to\nhandle notifications at the expected rate. It is important for developers to\nconsider situations that may cause failure responses - including `500` responses\nfrom their web container, timeouts, or upstream failures. Things to consider\ninclude:\n\n- Verify that your DDoS protections are configured to handle the expected rate of webhook notifications.\n- Confirm that resources such as database connection pools don't run out and produce timeouts or `500` responses.\n\nDevelopers should design their systems so the processing of RBM events occurs\nasynchronously and doesn't prevent the webhook from returning `200 OK`.\n\n\nIt is important to **not** process the RBM event within the webhook itself. Any\nerror or delay during processing may impact the webhook return code:\n\n\n### Behavior on delivery failure\n\nRBM uses a backoff and retry mechanism when it receives a response other than\n`200 OK` from a webhook call. RBM will increase the time it waits between\nretries up to a maximum of 600 seconds. Retries will continue for **7 days**,\nafter which the message will be dropped.\n\n### Implications of agent-level webhooks\n\nRBM queues messages for a partner on one queue. Where a partner is using\nagent-level webhooks, it is important to bear in mind that the failure of one\nwebhook will impact delivery to other webhooks. Webhooks belonging to other\nagents will be called during the backoff period of a failed message.\nHowever, as failed messages queue up for retry, overall delivery rates will fall\nand other agents will be impacted.\n\nIt is important that developers understand this model and code accordingly - as\nfar as possible, accepting messages and queueing them for processing to\nminimize the opportunity of returning a failure.\n\n### Next steps\n\nOnce you configure your webhook, your agent can\n[receive messages](/business-communications/rcs-business-messaging/guides/build/messages/receive)\nfrom your\n[test devices](/business-communications/rcs-business-messaging/guides/build/test).\n[Send a message](/business-communications/rcs-business-messaging/guides/build/messages/send)\nto validate your setup."]]