Teams reach for n8n when the CRM has to talk to something the CRM does not know about — a warehouse database, an internal service, a model API. Then the first hour goes into a question the tutorials skip: there is no ready-made node to drag onto the canvas. The connection is real and it is not hard, but it is assembled from generic blocks, and the pieces that break later are always the same ones. Here is the working shape of a Bitrix24 (Alaio) and n8n setup, in both directions.

Is there a Bitrix24 node in n8n?

Not a first-party one. n8n's own Bitrix24 page points you at the HTTP Request node with generic authentication, which is the honest answer: you call the REST API yourself. Community packages exist and some of them cover CRM entities, tasks and telephony properly, but they are maintained by third parties, they lag behind API changes, and on managed n8n instances installing them is a policy decision rather than a click. For a scenario that touches three or four methods, the HTTP Request node is less work than auditing a package — the API is plain JSON over HTTPS, and one node handles any method.

How does n8n write data into Bitrix24?

Through an inbound webhook. In the portal you create one under developer resources, pick the scopes it may use, and get a URL shaped like https://<portal>/rest/<user-id>/<token>/<method>.json — authorization is the URL itself, so the HTTP Request node needs no credentials beyond keeping that URL secret. Method name and parameters ride in the request exactly as the docs describe them: crm.item.add, crm.item.update, tasks.task.add.

Two properties of that URL decide most of what happens later. It acts with the rights of the employee who created it, so a scenario that cannot see a pipeline fails with an access error while the token is perfectly valid — create webhooks under a service account, not under whoever happened to be logged in. And the token does not rotate: it lives until someone deletes it or deactivates that employee, which makes it convenient and makes leaking it expensive. The mechanics of both directions are laid out in the webhooks guide.

How do I trigger an n8n scenario from Bitrix24?

Two routes, and they behave differently. An outbound webhook in the portal subscribes to events — a deal updated, a lead created — and posts to the URL of your Webhook node. It fires on every matching event, whether the change came from a person, an import or another integration, and the payload arrives form-encoded rather than as JSON, which is why the node shows fields instead of a body on the first run.

The other route is to call n8n from the workflow itself: an HTTP request GET/POST step inside an automation rule hits the Webhook node's URL at the exact point in the process where you want it, with only the data you chose to send. Build JSON from fields assembles the payload from workflow values without hand-escaping quotes, and Extract value from JSON by path reads whatever n8n replies back into the process. Where the delivery must not be lost — an order pushed to production, a document sent for signing — Reliable webhook retries on its own schedule and reports how many attempts it took, instead of failing once and moving on.

Which half of the scenario should stay in the portal?

The half that never leaves it. Moving a stage, filling a field, creating a task, branching on a condition — routing that through an external scenario buys a round trip, a second place to debug and a quota to watch, and buys nothing else. The reasonable split is: n8n owns the systems outside the portal, the portal owns its own records, and one call connects them. The cost side of that decision is worked through in the comparison of connectors and in-portal automation; the in-portal side is ordinary workflow automation in Bitrix24.

Why does the scenario stay silent?

Start with the n8n end: the Webhook node has separate test and production URLs, and the production one only answers when the workflow is active — a scenario built and verified in test mode goes quiet the moment you stop watching it. Then the portal end: an outbound webhook bound to the wrong event, or to an entity type the rule never touches, produces no request at all, so an empty execution list is a subscription problem rather than a network one.

If requests do arrive and come back with errors, read the string instead of retrying — the REST API error codes map sorts them by which side has to act. Bursts are their own class: the API allows a couple of calls per second per portal, and a loop that iterates a few hundred records without pacing runs into QUERY_LIMIT_EXCEEDED. And when the trigger is an automation rule that never started, the checklist is in automation not running.

Where to go from here

Sketch your scenario as two lists — steps that touch outside systems, steps that only touch portal records — and move the second list into the workflow. What remains is usually one webhook in each direction, which is a much smaller thing to keep alive. The blocks for the portal side are in the robot catalog, and if the one you need is missing, describe the task: Roboteka builds missing automation rules for free and ships them to the shared library.