在 Coexistence 号码上将 WhatsApp 连接到 Bitrix24 CRM

n8n 如何与 Bitrix24 通信？

通过入站 Webhook。在 Bitrix24 中，它不是接收器，而是一份凭据。您在 Bitrix24 开发者资源中创建它，选择它可使用的权限范围，并得到一个 URL，其中包含您的门户地址、创建者的用户 id 和一个密钥。在该 URL 后追加方法名，就会以该用户的身份、按该用户的权限调用 REST API。

因此在 n8n 中，每个 Bitrix24 步骤都是一个 HTTP Request 节点，向该 URL 加上 crm.lead.add.json 之类的方法发送请求。无需完成 OAuth 流程，也无需发布应用。请只授予该 Webhook CRM 权限范围，并用权限覆盖工作流所需线索和联系人的用户来创建它，因为 Bitrix24 按该用户检查访问权限。

工作流会调用哪些 Bitrix24 方法？

共三个，在 n8n 的 Webhook 节点收到来自 Meta 的消息之后依次调用。

crm.duplicate.findbycomm 使用类型 PHONE 和发件人号码，返回持有该号码的所有线索、联系人和公司的 id。这是正确的查找方式，因为它一次搜索三类记录，并且专为按通信方式匹配而设计，而不是按文本字段匹配。

如果没有返回结果，crm.lead.add 会创建一条线索，以 WhatsApp 个人资料名称作为标题，并把号码填入电话字段。随后 crm.timeline.comment.add 把消息文本作为评论写入该记录，需要 ENTITY_TYPE、ENTITY_ID 和 COMMENT。评论与通话、电子邮件一起出现在记录的时间线中，也就是销售人员本来就会查看的地方。

POST https://yourcompany.bitrix24.com/rest/1/<secret>/crm.duplicate.findbycomm.json
{ "type": "PHONE", "values": ["14155550188"] }

POST .../crm.lead.add.json
{ "fields": { "TITLE": "WhatsApp: Maria", "PHONE": [{ "VALUE": "14155550188", "VALUE_TYPE": "MOBILE" }] } }

POST .../crm.timeline.comment.add.json
{ "fields": { "ENTITY_TYPE": "lead", "ENTITY_ID": 4211, "COMMENT": "do you have anything friday?" } }

速率限制如何影响工作流设计？

Bitrix24 用漏桶机制计量 REST 调用。每个请求都会增加计数器，计数器每秒按固定速率下降，一旦超过阈值，下一个请求就会收到 503 和 QUERY_LIMIT_EXCEEDED。在 Enterprise 套餐上，计数器每秒下降 5，阈值为 250；在其他所有套餐上，每秒下降 2，阈值为 50。

每条入站消息需要两到三次调用，所以平稳的消息流远远达不到上限。突发流量则不同：50 位客户在一分钟内回复同一条消息模板，最多就是 150 次调用。请将 HTTP Request 节点设置为失败后短暂等待再重试，并让工作流的执行逐个运行，这样突发流量会被逐步消化进 Bitrix24，而不会被拒之门外。

在手机上输入的回复会进入 Bitrix24 吗？

可以。在 Coexistence 号码上，WhatsApp Business 应用继续可用，有人从应用中回复时，Meta 会把这条发出消息的回显发送到同一个 Webhook 目的地，字段为 smb_message_echoes。

工作流中的第二个分支用与入站消息相同的方式处理这些回显，并把评论标记为发出。这样记录中就能按顺序显示完整对话，既有客户的话，也有商家的回复。

工作流通过 Cloud API 自己发送的回复，在发出时就已经在工作流手中，所以请在那一刻记录它们，而不是等待 Webhook 回传。

常见错误

• 把入站 Webhook URL 粘贴到客户端代码或共享文档中。其中的密钥拥有该 Webhook 被授予的全部权限范围。
• 用看不到全部线索的用户创建 Webhook。查找会漏掉记录，工作流随之创建重复项。
• 发送突发调用却不设置重试。Bitrix24 返回 503 QUERY_LIMIT_EXCEEDED，这些消息就永远到不了时间线。

常见问题

继续阅读