Connect WhatsApp to Bitrix24 CRM on a Coexistence number

How does n8n talk to Bitrix24?

Through an inbound webhook, which in Bitrix24 is not a receiver but a credential. You create it in the Bitrix24 developer resources, choose the scopes it may use, and get a URL containing your portal address, the id of the user who created it and a secret code. Appending a method name to that URL calls the REST API as that user, with that user's permissions.

So in n8n every Bitrix24 step is an HTTP Request node posting to that URL plus a method such as crm.lead.add.json. There is no OAuth flow to complete and no app to publish. Grant the webhook the CRM scope only, and create it from a user whose permissions cover the leads and contacts the workflow must see, since Bitrix24 checks access as that user.

Which Bitrix24 methods does the workflow call?

Three, in order, after the n8n Webhook node receives the message from Meta.

crm.duplicate.findbycomm with type PHONE and the sender's number returns the ids of any leads, contacts and companies holding it. This is the right lookup because it searches all three at once and is built for matching on communications rather than on a text field.

When it returns nothing, crm.lead.add creates a lead with the WhatsApp profile name as the title and the number in its phone field. Then crm.timeline.comment.add writes the message text as a comment on the record, taking ENTITY_TYPE, ENTITY_ID and COMMENT. The comment appears in the record's timeline beside calls and emails, where a salesperson already looks.

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?" } }

How does the rate limit shape the workflow?

Bitrix24 meters REST calls with a leaky bucket. Each request adds to a counter, the counter drains at a fixed rate each second, and once it passes a threshold the next request gets a 503 with QUERY_LIMIT_EXCEEDED. On Enterprise plans the counter drains by 5 a second with a threshold of 250; on every other plan it drains by 2 with a threshold of 50.

Each inbound message costs two or three calls, so a steady trickle never comes close. A burst does: fifty customers replying to the same template within a minute is up to 150 calls. Set the HTTP Request nodes to retry on failure with a short wait, and run the workflow's executions one at a time, so a burst drains into Bitrix24 rather than bouncing off it.

Do replies typed on the phone reach Bitrix24?

They can. On a Coexistence number the WhatsApp Business app keeps working, and when someone answers from it Meta sends an echo of the outgoing message to the same webhook destination, under the smb_message_echoes field.

A second branch in the workflow handles those echoes the same way as inbound messages, with the comment marked as outgoing. The record then shows the full conversation, with the customer's lines and the shop's answers in order.

Replies the workflow sends itself through the Cloud API are already in the workflow's hands when they go out, so log them at that moment rather than waiting for a webhook to come back.

Common mistakes

• Pasting the inbound webhook URL into client-side code or a shared document. The secret in it grants every scope the webhook was given.
• Creating the webhook from a user who cannot see all leads. Lookups then miss records and the workflow creates duplicates.
• Sending a burst of calls without retries. Bitrix24 answers 503 QUERY_LIMIT_EXCEEDED and those messages never reach the timeline.

Frequently asked questions

Keep reading