Bitrix24

v0.11.5

Last updated Oct 2, 2026

Bitrix24 nodes for n8n: CRM, product catalog with prices, stock and inventory documents, tasks and workgroups, business processes, universal lists, calendar and resource booking, employees and company structure, messenger and open lines, chatbots, Drive f

942 Weekly Downloads

2,647 Monthly Downloads

View on NPM GitHub Repository

Included Nodes

Bitrix24

Bitrix24 AI

Bitrix24 Business Processes

Bitrix24 Calendar

Bitrix24 Catalog

Bitrix24 Chatbot

Bitrix24 Chatbot Trigger

Bitrix24 Consents

Bitrix24 CRM

Bitrix24 Drive

Bitrix24 Employees

Bitrix24 Event Log

Bitrix24 Lists

Bitrix24 Messenger

Bitrix24 Messenger Trigger

Bitrix24 Open Lines

Bitrix24 Tasks

Bitrix24 Trigger

Description

@zenland-dev/n8n-nodes-bitrix24

n8n community nodes for Bitrix24: a CRM node with 268 operations
across 42 resources, a catalog node with 148 operations across 26 resources, a tasks node with 129
operations across 17 resources, a messenger node with 63 operations, an open lines node with 43, a Drive node with 36, a chatbot node with 34, an
employees node with 32, a calendar node with 21, a lists node with 19, a business process node with
10, an event log node with 5, a consents node with 3 and an AI node with 3, a node that calls any of
the ~1400 REST methods by name or in batches, a trigger for outgoing
webhooks, and two triggers that need no public URL: one for chat messages, one for messages and
commands sent to a bot.

Written from scratch against the official REST documentation
(bitrix24/b24restdocs, read on 14.09.2026). No code
from any other package.

Status: 0.10.2. Every operation of the CRM, tasks, Drive, chatbot, calendar, lists and event log
nodes was run against a live Bitrix24 portal, 143 of the 148 of the catalog node, 29 of the 32 of the
employees node, 57 of the 63 of the messenger node, 14 of the 43 of the open lines node, 7 of the 10 of the business process node, 2 of the 3 of the consents node and
1 of the 3 of the AI node: reads as they are, writes on objects the test created and deleted. What was
not run, and why, is under What was checked. Operations that work with a
limitation of Bitrix24 itself are listed under Quirks.

Installation
Credentials
Bitrix24 node
Bitrix24 CRM
Bitrix24 Tasks
Bitrix24 Messenger
Bitrix24 Open Lines
Bitrix24 Chatbot
Bitrix24 Drive
Bitrix24 Calendar
Bitrix24 Employees
Bitrix24 Business Processes
Bitrix24 Lists
Bitrix24 Catalog
Bitrix24 Event Log
Bitrix24 Consents
Bitrix24 AI
Bitrix24 Trigger
Bitrix24 Messenger Trigger
Bitrix24 Chatbot Trigger
Rate limits
Quirks worth knowing
What was checked
What is not here yet

Installation

In n8n: Settings → Community nodes → Install, then enter @zenland-dev/n8n-nodes-bitrix24.

Self-hosted, from the command line:

npm install @zenland-dev/n8n-nodes-bitrix24

Requires n8n 2.x and Node 20.19 or newer.

Credentials

Nine of the eleven nodes use Bitrix24 Webhook API, built from an inbound webhook. The chatbot
node and its trigger use Bitrix24 Chatbot Webhook API: the same fields plus a bot token, see
below.

Create the webhook in Bitrix24 under Developer resources → Other → Inbound webhook and tick
the permissions the workflows need: crm for the CRM node; task, tasks and sonet_group
for the tasks node; im for the messenger node and its trigger; imopenlines for the open lines
node, plus crm for its CRM chats; disk for the Drive node; bizproc for the business process
node and lists for the lists node; plus whatever modules you call through the Bitrix24 node. The webhook acts as the user who created it and sees only what that
user may see, so a webhook made by a sales manager cannot read another manager’s deals.

The credential has three fields instead of one URL.

Portal Subdomain and Portal Domain. mycompany and bitrix24.com for
mycompany.bitrix24.com. The domain is a closed list of the 23 zones Bitrix24 serves cloud
portals on (.com, .eu, .de, .ru, .kz, .com.br and so on). A webhook URL carries
its secret in the path, so a free-form address would let anyone who can edit the credential
send that secret to their own server. The list is enforced again inside the nodes, not only in
the dropdown. Self-hosted Bitrix24 on its own domain is not supported for the same reason.

The zones were found by resolving a random subdomain in each candidate: Bitrix24 zones answer
with wildcard DNS, .ua, .am, .az, .ge and .kg do not resolve, and .cz and .au
resolve to parking pages that have nothing to do with Bitrix24.

Webhook Token. The part of the webhook URL after /rest/, like 1/abcdef0123456789.
Pasting the whole URL works: only the tail is kept, and the host in it is ignored.

Requests per Second defaults to 2, the limit on every plan below Enterprise.

The credential is pinned out of the HTTP Request node (Allowed HTTP Request Domains is fixed
to none), and it has no authenticate block, so even a credential selected there would add
nothing to a request.

Bitrix24 Chatbot Webhook API

Through a webhook, Bitrix24 tells bots apart by botToken: a string you make up when the bot is
registered and send with every later call. Whoever has the webhook and the token can act as the
bot, so the token is a secret, and it lives in the credential rather than in a node parameter,
where it would travel inside every exported workflow.

The webhook needs the imbot permission, plus im if a bot should also read the webhook user’s

own events.

Bot Token: up to 40 characters; the documentation announces that registration refuses longer

ones from 06.08.2026, and the node refuses them already. 32 random letters and digits from a
password generator do.

Keep the token once a bot is registered with it. Another token cannot reach that bot, and the

node does not offer rotating it: the new token would have to be typed into a workflow.

One token can hold several bots. Every operation picks the bot from a list of the token’s bots.

Test calls imbot.v2.Revision.get, which checks the portal, the webhook and its imbot
permission. It cannot check the token: before a bot is registered with it, any token is as good
as another.

Bitrix24 node

The escape hatch. Anything the CRM node lacks, and every module that has no node yet, is one
call away here.

Call takes a method name and a JSON body, for example crm.item.list with
{"entityTypeId": 2, "select": ["title", "stageId"]}. Pagination has three modes. *First
Page Only sends one request. Follow Pages* repeats with start until Bitrix24 stops
sending next. Page by ID filters by the last ID received with start: -1, which tells
Bitrix24 not to count the total; on a large portal the count is what makes a page slow.

API Version switches to REST 3.0 (/rest/api/). Some newer methods exist only there:
main.eventlog., mail.mailbox., note., humanresources., timeman.record.*.

Execute Commands sends up to 50 named calls in one request, and a later command can use an
earlier result: {"id": "$result[list][items][0][id]"}. Such references only work inside one
request, which is why the node refuses a 51st command instead of splitting the list.

Call for Each Item is for bulk work. It makes the same kind of call once per input item and
packs them 50 to a request, so 500 new leads cost 10 requests instead of 500. Output items stay
paired with their inputs. With Continue On Fail on, a failed call becomes an error item and the
rest go through; with it off, the node stops, but every call of that run has already been sent.

Bitrix24 CRM

Built on the universal crm.item.* API, so field names are camelCase (title, stageId,
assignedById) and custom fields are ufCrm…. The older per-entity methods (crm.deal.add
and friends) are frozen by Bitrix24 and are not wrapped; call them through the Bitrix24 node if
an old integration needs their exact behaviour.

Fields come from the portal

Create, Update and Import show a field mapper filled from crm.item.fields. Custom fields are
in it with their labels, list fields become dropdowns with the portal’s own values, and stage
IDs come with the pipeline in front ( / ). A deal can have hundreds of
fields, so the mapper adds nothing by default: pick the fields you need. Nothing is required on Update. Read-only fields are left out, and so are
contacts and companies: crm.item.fields lists them as writable, under the same titles as
contactIds and companyIds, but writing them fails with error 100.

Anything the mapper cannot express goes into Fields (JSON), which is merged last and wins.
Clearing a field is done there too: the mapper skips empty inputs rather than sending blanks.

Leads, contacts and companies have a separate Phones, Emails and Messengers list. On Update
it only adds. To change or remove an existing value, write fm into Fields (JSON) as an
object keyed by the value’s ID:

{"fm": {"34": {"typeId": "PHONE", "valueType": "WORK", "value": "+49 30 1234567"}, "35": {"typeId": "EMAIL", "value": ""}}}

The first entry changes value 34, the second removes value 35: an empty value deletes. Keys
n0, n1… add new values, and the list’s entries go in under the n keys the object leaves
free. The same fm as an array only adds: an id inside an array entry is ignored. The value IDs
are in fm of Get, and of Get Many when Fields to Return is empty or *; with a list
of fields Bitrix24 leaves fm out.

Label takes the values Bitrix24 lists for each kind: work, mobile, home, fax, pager, mailing
and other for a phone; work, home, mailing and other for an email; work, home, Facebook, VK,
LiveJournal, Twitter and other for a website; Telegram, WhatsApp, Viber, VK, Facebook, Instagram,
Bitrix24 Network, Live Chat, Open Channel, Skype and other for a messenger. A label that does not
fit the kind goes out as Work, or as Telegram for a messenger.

Create runs automation, Import does not

Create behaves like a person pressing Save: automation rules, workflows, notifications to
the responsible user. Import (crm.item.import) creates the record without automation
rules and workflows. Use it for tests on a portal where a new deal would send a client an SMS.

Import takes phones, emails and messengers too, but not in fm: crm.item.import answers
The value of an argument 'value' must be of type BitrixCrmMultifieldCollection to the form
every other crm.item method uses. The node sends them as PHONE, EMAIL, WEB and IM
lists instead, including fm written into Fields (JSON). Before 0.4.1 an Import with contact
details failed.

The documentation also promises that Import keeps historical createdTime. In practice it
does not: any createdTime older than records the portal already has, even by an hour, is
refused with The value of "Date created" cannot be less than that of any other items
(CRMFIELDERRORVALUENOT_VALID). Migrating old data with its dates needs a portal that is
still empty.

Get Many reads by ID

Get Many sorts by ID and asks for the next 50 above the last one, with no total count. Set
Order (JSON) and it falls back to Bitrix24’s offset paging, which counts the total on
every page and gets slower as the portal grows.

Before creating a client, Duplicate → Find by Phone or Email answers found, plus lead,
contact and company IDs. Bitrix24 itself returns [] for no match and an object for a match;
the node smooths that into one shape.

Bitrix24 Tasks

Tasks, and everything a task lives in: checklists, time, results, dependencies, kanban
stages, templates, flows, workgroups and scrum. The webhook needs the task permission, plus
sonet_group for workgroups and tasks for the operations marked REST 3.0 below.

| Resource | Operations |
|—|—|
| Task | Create, Get, Get Many, Update, Delete, Get Fields, Start, Pause, Defer, Complete, Reopen, Approve, Return for Rework, Delegate, Start Watching, Stop Watching, Add to Favorites, Remove From Favorites, Pin, Unpin, Mute, Unmute, Add Comment, Get History, Get Counters, Check Access, Attach File, Get Daily Plan |
| Checklist Item | Create, Get, Get Many, Update, Delete, Complete, Reopen, Move After |
| Time Entry | Create, Get, Get Many, Update, Delete |
| Result | Create, Create From Chat Message, Get Many, Update, Delete |
| Dependency | Create, Delete, Get Many |
| Kanban Stage | Create, Get Many, Update, Delete, Move Task, Check Move Permission (group kanbans and My Plan) |
| Custom Field | Create, Get, Get Many, Update, Delete, Get Types, Get Fields |
| Task Template | Create, Get, Update, Delete, Get Fields |
| Template Checklist Item | Create, Get, Get Many, Update, Delete, Complete, Reopen, Move After, Move Before, Attach Drive Files, Remove Attachments |
| Flow | Create, Get, Update, Delete, Activate, Deactivate, Toggle Pin, Check Name |
| Workgroup | Create, Get, Get Many, Get My Groups, Update, Delete, Set Owner, Check Feature Access |
| Workgroup Member | Add, Invite, Request to Join, Get Many, Set Role, Remove |
| Scrum Sprint | Create, Get, Get Many, Update, Delete, Start, Complete Active Sprint, Get Fields |
| Scrum Epic, Scrum Backlog | Create, Get, (Get Many), Update, Delete, Get Fields |
| Scrum Kanban Stage | Create, Get Many, Update, Delete, Add Task, Remove Task, Get Fields |
| Scrum Task | Get, Update, Get Fields |

Two APIs under one node

Bitrix24 is moving tasks to REST 3.0, and on a cloud portal in September 2026 both answer. The
node uses the classic tasks.task.* for almost everything, because REST 3.0 cannot yet filter a
task list by anything but ID. REST 3.0 is used where the classic API has nothing: **Add
Comment, Result → Create / Update / Delete / Create From Chat Message** and
Dependency → Get Many.

Fields are written in UPPERCASE and come back in camelCase: RESPONSIBLEID goes in,
responsibleId comes out. That is Bitrix24, not the node.

Comments are chat messages now

Since the new task card (module tasks 25.700), a task’s discussion is a chat. Add Comment
posts into it. The old comment methods (task.commentitem.*) no longer read, change or delete
anything on such portals, so the node does not wrap them. The chat is read with **Bitrix24
Messenger → Message → Get Many** and the Dialog ID chat; chatId is in every task.

The comment events of the Bitrix24 Trigger changed with it. According to the documentation,
Task Comment Updated and Task Comment Deleted are not sent for such tasks, and Task Comment Added
comes with ID 0 and the message ID in MESSAGE_ID. A real delivery was not tried.

Statuses

status is a number: 2 pending, 3 in progress, 4 awaiting control, 5 completed, 6 deferred,
7 declined. Change it with the operations, not by writing STATUS: they run the checks a
person pressing the button would. A task with Require Result does not complete until
Result → Create; a task with Task Control goes to 4 and waits for Approve or
Return for Rework by its creator.

Get Many reads by ID

As in the CRM node: sorted by ID, the next 50 above the last one, no total. Order (JSON)
switches to offset paging, which counts the total on every page and gets slower as the task list
grows.

Bitrix24 Messenger

Chats, messages, files and notifications, as the user who owns the webhook. Everything this node
sends comes from that user, and everything it reads is what that user sees: a chat they are not
in does not open.

Dialog ID

A conversation has one address in three spellings: chat123 for group chat 123, sg12 for the
chat of workgroup 12, and a plain user ID such as 7 for the private chat with user 7. Operations
that only make sense for group chats take Chat ID, a number, and accept chat123 as well.

Chat → Find by Linked Object gets the chat of a task (TASKS_TASK and the task ID), a CRM
record (CRM and DEAL|1663), a workgroup, a calendar event or a call. Create refuses to bind a
new chat to a workgroup: every group already has its chat, and the documentation warns that a
second one breaks the chats of the group’s tasks.

Sending

Message → Send takes text with BB codes ([B]bold[/B], [USER=7]Name[/USER],
[URL=https://example.com]link[/URL]), plus optional Attachment (JSON), Keyboard (JSON) and
Context Menu (JSON). Keyboard buttons that only run a bot command are dropped by Bitrix24 when a
user sends the message; links and ACTION buttons stay.

Update refuses an empty text. Bitrix24 treats an empty MESSAGE as “delete this message”, and a
field mapped from an empty expression should not do that silently.

Notification → Send puts a notice into a user’s bell instead of a chat, from the webhook user or
as a system notice. The documented tags that replace or group notifications do nothing through a
webhook: Bitrix24 does not store them, so the node does not offer them.

Reading

Message → Get Many reads the latest messages, or pages back from a message or forward from it,
50 per request. Each message gets its author and files joined in, which Bitrix24 returns as
separate lists. Search finds messages in one chat by text and dates, 200 per request.

Reading messages and notifications does not change unread counters. Marking is done only by the
Mark operations.

Files

Upload sends binary data into a chat in one request (im.v2.File.upload, up to 100 MB).
Download puts a chat file into binary data. There is no “get download link” operation on purpose:
the link Bitrix24 returns to a webhook is /rest///download/…, so it carries the
webhook secret. The node fetches it inside the operation, only from the portal it came from, and
keeps it out of the output and out of error messages.

Event Queue

Bitrix24 can record the messenger events of a user and hand them out on request, which needs no
public address. Subscribe starts recording new messages, deletions, reactions and new members in
every chat of the webhook user. Get Many reads them; passing the nextOffset of the previous read
confirms, and deletes, what came before. Events are kept for 24 hours. The **Bitrix24 Messenger
Trigger** does all of this by itself.

Bitrix24 Open Lines

The contact center: conversations with clients who write from a website chat, Telegram, WhatsApp
and other connected channels. Messages sent here reach clients in their messenger.

| Resource | Operations |
|—|—|
| Dialog | Get, Get Chat by User Code, Get History, Start Session, Start Session From Message, Join, Take Over, Pin or Unpin, Pin All, Unpin All, Set Silent Mode, Rate as Supervisor, Create Lead, Save as Quick Answer |
| Operator | Take, Skip, Transfer, Finish, Finish Another Operator’s, Mark as Spam |
| CRM Chat | Get Many, Get Latest Chat ID, Add User, Remove User, Send Message |
| Open Line | Create, Get, Get Many, Update, Delete, Get Public Page Link, Connect Network Line, Send Network Message |
| Statistics | Get Summary, Get Sessions, Get Session Metrics, Get Transfers, Get Ratings, Get Operator Load |
| Bot Dialog | Send Automatic Message, Hand to Free Operator, Transfer, Finish |

A conversation is an open channel chat (Chat ID), and each round of it, from the first client
message to closing, is a session (Session ID). To reach the client of a deal, find the chat with
CRM Chat → Get Many or Get Latest Chat ID, then CRM Chat → Send Message from an employee who
is in that chat.

Open Line → Create and Update show the settings people usually change: queue, distribution,
working hours, days off, welcome message, rating request. The other sixty or so settings of
imopenlines.config.add go into Other Settings (JSON) by their names.

Statistics reads the imopenlines.v2 reports: totals for a period with breakdowns by channel,
hour and operator; sessions with filters; per-session metrics and transfer history (any number of
IDs, split into the batches Bitrix24 allows); client ratings; the current load of operators. A period
is at most 366 days. These methods need access to open channel reports on the plan and for the user.

Bot Dialog acts for a chatbot connected to a line. Through a webhook Bitrix24 must be told which
bot: give the botToken it was registered with in imbot.v2, the Bot Token of the Bitrix24 Chatbot
Webhook API credential.

Connectors (imconnector.*) are not here: Bitrix24 does not let a webhook call them.

Bitrix24 Chatbot

A bot of your own in the Bitrix24 messenger (Chatbots 2.0, imbot.v2): it has its own name and
avatar, people write to it privately or mention it in group chats, and it answers with text,
cards, buttons and files. Everything it sends comes from the bot, not from the webhook user.

Getting a bot going

1. Create the Bitrix24 Chatbot Webhook API credential with a token of your own.
2. Run Bot → Register once, with a code such as support_bot and a name. Registering the same
code again returns the existing bot unchanged, so leaving this node in a workflow does no harm.
3. Put a Bitrix24 Chatbot Trigger on the bot, and answer with Message → Send to the
chat.dialogId of the event.

A conversation is a Dialog ID: chat123 for group chat 123, or a user ID such as 7 for the
private chat of the bot with user 7. In an event from a private chat, chat.dialogId is already the
other person’s ID, so it goes straight back into Send.

Bot types

Type is set at registration and cannot be changed later.

Bot gets every message of its private chats, and in group chats only the messages that mention

it ([USER=]…[/USER]). This is the one most bots need.

Supervisor and Personal Assistant get every message of every chat they are in, and only

they may read with Message → Get and Get Context. A plain bot asking gets
BOTTYPENOT_ALLOWED. Get Context returns up to 50 messages on each side of one, with authors,
which is what an AI agent needs to see the conversation.

Open Channel Bot answers clients in open channels and otherwise behaves like Bot.

Buttons and commands

Keyboard (JSON) puts buttons under a message. A button with LINK opens a page, one with
ACTION inserts or sends text on the person’s side, and one with COMMAND runs a slash command of
the bot:

[{"TEXT": "Talk to a manager", "COMMAND": "manager", "COMMAND_PARAMS": "sales", "BLOCK": "Y"},
 {"TYPE": "NEWLINE"},
 {"TEXT": "Price list", "LINK": "https://example.com/prices"}]

The command has to exist: Command → Register it first (manager, with a title for the command
list). Typing /manager and pressing the button both arrive as a Command Called event; the
event’s command.context says which, textarea or keyboard. Command → Answer replies in the
chat the command came from. According to the documentation that works even in a chat the bot is not
in, as a system line; only answers in the bot’s own chats were tried.

The node adds the bot’s ID to every keyboard it sends, because Bitrix24 warns that an updated
keyboard without one may send the press to the wrong bot.

Chat → Set Input Field turns typing off in a chat, so people can only press buttons.
Show Activity Indicator shows “typing…” or an agent status such as “Agent is searching for
information…” for up to 600 seconds while a workflow prepares the answer.

Events and files

Event → Get Many reads the bot’s queue by hand; the trigger does the same on a schedule. Passing
an offset deletes the events before it for every reader of that bot. Include Webhook User Events
adds the webhook user’s own messenger events (ONIMV2…) to the same read; that needs the im
permission and Bitrix24 Messenger → Event Queue → Subscribe first.

File → Download puts a chat file into binary data. The one-time link Bitrix24 hands out for it
contains the webhook code, as it does in the messenger node, so it is fetched inside the operation
and never shown.

Bot → Update changes the name, profile, flags and background, and can switch Event Delivery
to a webhook URL of your own. Bitrix24 then posts each event there with an OAuth token of the bot
inside, and does not retry a failed delivery. The trigger needs the default, Keep for Polling.

Bitrix24 Drive

Files and folders on Bitrix24 Drive, as the webhook user: its personal drive, the drives of its
workgroups and the company drive, plus any drive it has been given access to.

| Resource | Operations |
|—|—|
| File | Upload, Upload New Version, Download, Get, Search, Rename, Copy, Move, Move to Trash, Restore From Trash, Delete Permanently, Get Public Link, Get Versions, Get Version, Download Version, Restore Version, Get Fields |
| Folder | Create, Get, Get Items, Rename, Copy, Move, Move to Trash, Restore From Trash, Delete Permanently, Share With User, Get Public Link, Get Fields |
| Storage | Get by Owner, Get, Get Many, Get Root Items, Get Fields |
| Attached File | Get, Download |

Where a file goes

Everything on Drive lives in a folder, and a drive’s top level is a folder too: its ID is
ROOTOBJECTID. Storage → Get by Owner finds it for the webhook user, another user, a
workgroup or the company in one call. File → Upload and Folder → Create take a folder
ID, or a storage ID with Drive Root.

A webhook made by an administrator sees the drive of every user and workgroup, so **Storage → Get
Many** with Return All can take many requests.

Access Rights on both operations hand the new folder or file to someone besides whoever the
parent folder already lets in: an access code (U35 a user, D12 a department, DR12 that
department with the ones under it, everybody) and a level from the portal’s own list. Deny*
turns a row around — it takes the level away from that person and beats the rights the parent
folder passes down, which is how you keep one folder out of sight inside a shared one. Rights on a
folder inside a folder work since 17.09.2026; before that Bitrix24 took them only at a drive root,
and Folder → Share With User was the only way to hand over a subfolder afterwards.

Upload and download

Upload takes a file from binary data and sends it inside the request, base64-encoded; a 10 MB
file uploaded and came back byte for byte. **If the Name Is
Taken** either adds a number, report (1).pdf, or fails with File with this name already exists.

Download puts the file into binary data. Bitrix24 hands out a download link for that, and
for a webhook the link has the webhook code in it: /rest///download/ for Drive files, auth[ap]= in the uf.php link of an attached file. So the node fetches the link inside the operation and removes DOWNLOAD_URL from every output. To give someone a file, use Get Public Link: it opens the file for anyone who has it, without signing in. The API has no method to switch such a link off again.


Attached File reads files attached to feed posts, comments and list items by attachment ID.

Tasks in the new task card keep their files in the task chat instead and have nothing in

ufTaskWebdavFiles.
Trash, versions and search
Move to Trash is undone by Restore From Trash, but only with the ID: the trash cannot be

listed through the API. Restoring a folder needs an administrator, according to the

documentation. Delete Permanently skips the trash.
Upload New Version replaces the contents and keeps the file's name and ID. Do not count on

the old contents staying: after every new version Get Versions listed only the latest one,

also with uploads more than a minute apart, and the earlier contents could not be downloaded any

more.
Move works within one drive. Moving a file or a folder to another drive answered false and

left it where it was; the node turns that into an error.

Copy worked across drives, a folder with its contents included, so copy and delete the

original instead. Copy does not rename: when the target folder already has a file or folder of

that name, Bitrix24 answers DISKOBJ22000 and makes no copy.
Share With User gives one person access to a folder. It answered true for another user and

false for the webhook user itself.
Search looks through names and the text of documents, 3 to 255 characters, on every drive the

webhook user can read or within one drive or folder. By the documentation it pages no further than

the 1000th result, so the most it returns is 1050. Files uploaded two minutes earlier were found on

the first try.
Filters
Drive filters are narrower than the documentation says, and whatever they do not support is

dropped without an error, so an unsupported filter returns everything:
A list matches any of its values when written as a plain array, {"ID": [12, 15]}. The @ and
  !@ prefixes from the documentation were ignored.
>, >=, <, <=, ! and % (contains) work on the fields that Get Fields marks
  USEINFILTER. For files and folders these are ID, NAME, TYPE, CODE, STORAGEID, PARENTID, the

  dates and DELETEDTYPE; a filter on SIZE or CREATEDBY in Get Items returned every item.

  Get Versions does filter on SIZE.
A date is read as the webhook user's own local time, and offsets are not understood. A value
  ending in Z or in an offset such as +02:00 matched nothing, while the same moment written as

  the user's local time without an offset matched to the minute. Get Items → Updated After

  converts the date for you, from the workflow's time zone to the webhook user's (or the portal's,

  when the user has none set). In Filter (JSON) write it that way yourself:

  {".

Bitrix24 Calendar
Events in the calendars of employees, workgroups and the company, the calendars themselves, the

resources a CRM booking field offers, and the settings behind them. The webhook needs the

calendar permission.
| Resource | Operations |

|---|---|

| Event | Create, Get, Get Many, Get Upcoming, Update, Delete, Get Availability, Get Meeting Status, Set Meeting Status |

| Calendar | Create, Get Many, Update, Delete |

| Booking Resource | Create, Get Many, Update, Delete, Get Bookings |

| Settings | Get Portal Settings, Get User Settings, Update User Settings |
Whose calendar
Every event belongs to an owner, and the owner is two parameters: Calendar Type and **Owner

ID**. For a user calendar, Owner ID 0 means the user the webhook acts as, and the node fills in its

ID. A group calendar has no default owner, so it needs the ID of the workgroup or project. The

company calendar always has owner 0.
Event → Get Upcoming is the one place where the owner is optional, and Bitrix24 has a trap

there: it reads the webhook user's own calendar unless the type and the owner arrive together and

For the Webhook User is off, and a missing For the Webhook User counts as on. The node sends

the owner whenever Calendar Type is set and turns the flag off unless you set it yourself, so

picking Company or Group gets you that calendar. Leave Calendar Type out and you get what the

method gives by default: the events of the webhook user across their calendars.
One owner can keep several calendars — work, trips, a project. Calendar lists, adds, renames

and deletes them, and in Event → Create the Calendar parameter either names one or leaves the

choice to Bitrix24. A webhook made by an ordinary user can only add calendars to that user;

an administrator can add them to anyone.
The organizer of an event the node creates is always the webhook user. Bitrix24 has no way to hand

an event over to someone else afterwards: to change the organizer, delete the event and create it

again on behalf of that person. Organizer User ID in Update is for the opposite case — the

webhook user editing a meeting somebody else runs, and it has to name the current organizer or the

call is refused.
Time zones
Bitrix24 takes either a full ISO-8601 string with an offset, and then ignores any time zone given

next to it, or a plain date and time together with a zone name. The node sends the second form: your

Start and End are converted to wall-clock time in the workflow's time zone, and that zone

goes with them, so the event keeps the zone you meant rather than one the portal guesses. **Time

Zone** in the additional fields overrides it — write it as Europe/Riga.
All Day sends the dates alone, without a time and without a zone, which is what Bitrix24 calls

skip_time. The dates of Get Many, Get Availability and Get Bookings are periods, so

they go as plain days, in ISO form: Bitrix24 reads 2026-09-16 and 2026-09-16 10:00:00, while a

day written as 16/09/2026 is not understood and silently widens the period to years.
A period is open at its end. From and To on the same day return nothing at all, and a

one-day event is only found by a period that reaches past it — take the next day as To.
Dates come back the way the portal writes them, DD/MM/YYYY hh:mm:ss or MM/DD/YYYY hh:mm:ss am

depending on its language, so they are text and not ISO. To compare or sort, use DATEFROMTS_UTC

and DATETOTSUTC, which are timestamps, and TZFROM for the zone the event is held in.
Participants and answers
Attendee User IDs invites people: the node marks the event as a meeting, and everyone on the

list gets an invitation to accept or decline. On Update the list replaces the current one. Removing

every participant at once is the one case the API keeps to itself — it takes a meeting flag with an

empty list, which the node cannot express; Bitrix24 node → Method → Call on

calendar.event.update does it.
Meeting Settings decides whether the organizer hears about answers, whether guests may invite

others, whether the guest list is visible and whether an edit asks everyone to confirm again.
Get Meeting Status and Set Meeting Status answer for the webhook user only, not for anyone

else on the list, and they need an event that is a meeting: on an event with no participants Get

fails with Error while retrieving status and Set answers success while storing nothing.
Get Availability takes user IDs and a period and returns one row per user, with the events that

fill their time — a user with nothing booked comes back with an empty list, which is what makes it

usable for finding a free slot. Only events that take up time are counted: an event whose

Accessibility is Free does not show up there, while Busy and an all-day event do.
Recurring events
Recurrence repeats an event daily, weekly, monthly or yearly, with an interval, the weekdays it

falls on, a number of repeats or a last day. Updating one of them asks which part of the series to

change: the whole event, only this occurrence, or this one and the ones after it. The last two need

the date of the occurrence you mean.
A weekly rule always names its weekdays, and if you pick none the node uses the weekday the event

starts on. That is not only the obvious meaning — Bitrix24 left to itself stores {MO: MO} for an

event starting on any other day, and such an event then disappears from every list: it is created,

it can be read by ID, and calendar.event.get never returns it.
Changing part of a series makes Bitrix24 split it, and the answer can then be an object instead of

an ID: id of the old series, recEventId of the new one, and the date and zone it starts at. The

node passes through whichever of the two comes back.
Get Many returns a row per occurrence in the period, not one row for the series, and the

occurrences carry the PARENT_ID of the event the series belongs to.
Resource booking
A booking resource is a room, a car, a piece of equipment — something clients take for a while.

Technically a resource is a calendar and a booking is an event in it, but the two live under

calendar.resource.* and the node keeps them there.
Create adds a resource; it starts taking bookings once a resource booking field in a lead or

deal form is set to offer it, which only the form editor can do. Get Bookings looks either at

resources — everything booked for them — or at the booking IDs a CRM record holds, and Bitrix24

takes one of the two, never both. The IDs come from a custom field of type resourcebooking, read

with the Bitrix24 CRM node.
Settings
Get Portal Settings reads the working hours, weekends and holidays every calendar of the portal

follows; the API cannot change them. Get User Settings and Update User Settings work on the

webhook user alone — its default view and calendar, whether tasks and declined events show, the

synchronisation period, and the time zone the portal thinks that user is in, which is worth reading

when event times come out shifted.
Update keeps the settings you leave out: writing one flag left every other key of a live account

as it was. Settings (JSON) covers what has no field of its own, defaultReminders and

defaultSections.
Bitrix24 Employees
The people on the portal and what surrounds them: the employee card, the company structure, the

working day and the time reports. The webhook needs the user permission, plus department for

the structure and timeman for working time.
| Resource | Operations |

|---|---|

| Employee | Get, Get Many, Search, Get Current, Invite, Update, Get Fields |

| Custom Field | Create, Get Many, Update, Delete |

| Department | Create, Get, Get Many, Update, Delete, Get Fields |

| Working Day | Open, Close, Pause, Get Status, Get Settings, Get Schedule |

| Work Time Report | Explain an Absence, Get Reports, Get Report Employees, Get Report Access, Get Settings, Update Settings |

| Office Network | Get Many, Set, Check |
Turning a person into an ID
Every other Bitrix24 node asks for employees as numbers: the responsible person of a task, the

participants of an event, the head of a department. Employee → Get Many and Search are what

turn an email, a name or a department into that number.
The two differ in how they look. Get Many filters on fields — exact values, with a comparison

in front of the field name, and any field of the card, including custom ones. Search takes one

phrase and looks through the first name, last name, job title and department name at once, or those

fields one by one; Bitrix24 refuses the two ways together, and so does the node.
The filter of Get Many is flat: ACTIVE, UF_DEPARTMENT and the rest sit next to sort and

select, not inside a filter object the way CRM writes them. Filter (JSON) follows that,

so a comparison goes into the key: {">LAST_LOGIN": "2026-01-01T00:00:00+03:00"}.
Both methods leave out bots, mail users, extranet users and Open Channel accounts, so an ID that

belongs to one of those comes back as nothing found. Fields to Return makes the call faster: a

list without custom fields skips loading them altogether.
Writing to people
Invite creates an employee and sends them the standard invitation email — a real letter to a

real address, and one more seat on the plan. Update changes a card, and Active off in it is

what Bitrix24 calls dismissal. Both need a webhook made by an administrator.
Custom Field adds a field to the card of every employee at once, and Bitrix24 upper-cases its

code and puts UFUSR in front: BADGE is stored as UFUSRBADGE, and that longer name is what

Get Many and the employee card return. Whether the field holds one value or several is decided when

it is created and cannot be changed afterwards.
Company structure
Department is the classic company structure: a tree with one top-level department, a head per

department and any depth below. Employees belong to departments through their UF_DEPARTMENT, so

moving somebody is an Employee → Update, not a department operation.
The node does not cover the newer humanresources.* org structure that Bitrix24 is moving to —

those 24 methods answer ERRORMETHODNOT_FOUND on a portal without it, and there was nowhere to

check them. Adding them later breaks nothing, since they would be new operations.
Working time
Working Day is the timesheet of one person: Open starts the day, Pause puts it on a break, Open

again continues it, Close ends it. The API writes into a real timesheet and has no way to remove an

entry afterwards, so a day opened by mistake stays in the reports. Times other than now need a

reason, unless the employee has a flexible schedule — that is Bitrix24's own rule, not the node's.
Work Time Report is the time control module: a month of an employee with every working day, how

long it lasted against the schedule, and the absences recorded in it. The days sit inside report

in the answer, not at the top. Get Report Access says whether the module is on at all and whose

reports the webhook user may read.
Office Network holds the address ranges that count as the office. Set replaces the whole

list — whatever is not in the request stops being the office — so read the current ranges first and

send them back together with the new one.
Bitrix24 Business Processes
Business processes of the portal: starting one on a record, seeing what runs, and answering the

tasks a process puts in front of people. The webhook needs the bizproc permission, **and the

webhook has to belong to an administrator** — Bitrix24 answers ACCESS_DENIED to everyone else on

most of these methods.
| Resource | Operations |

|---|---|

| Workflow | Start, Get Instances, Terminate, Delete |

| Task | Get Many, Complete, Delegate |

| Template | Get Many |

| Event | Send Result, Write Log |
Naming the record
A process always runs on a document, and Bitrix24 names one with three strings: a module, a PHP

class and an ID. The node asks for Document Type and Record ID instead and writes them out:
| Document Type | What goes to Bitrix24 |

|---|---|

| Deal, Lead, Contact, Company | ['crm', 'CCrmDocumentDeal', 'DEAL_777'] |

| Quote, Invoice | ['crm', 'BitrixCrmIntegrationBizProcDocumentQuote', 'QUOTE_5'] |

| Smart Process Item | ['crm', '…DocumentDynamic', 'DYNAMIC1471'], with Container ID the process |

| List Element, News Feed Process | ['lists', 'BitrixListsBizprocDocumentLists', '9'], with Container ID the list |

| Drive File | ['disk', 'BitrixDiskBizProcDocument', '88'], with Container ID the storage |
Three of them carry a container: a smart process item, a list element and a Drive file are only

addressable together with the process, the list or the storage they live in. Container ID shows

up for those three and is required there.
Template → Get Many uses the same picker to answer a narrower question — which templates can run

on deals — and sends the type without a record: ['crm', 'CCrmDocumentDeal', 'DEAL'].
Starting and stopping
Workflow → Start takes the template ID and the record, and answers a workflow ID: a string like

66e412fdc9bd44.36306599, not a number. Every other Workflow operation takes that string.
Terminate stops a process and keeps what it has done, with an optional line for the log.

Delete removes the process and its data altogether. Get Instances lists what is running,

filtered by template, by starter or by record, and adds entityType and entityId next to

Bitrix24's own DEAL_777.
Tasks of a process
A running process stops at a person: approve this, acknowledge that, fill in a number. **Task → Get

Many reads those, Complete answers one, Delegate** hands several to somebody else.
Which answers a task takes depends on its kind, and the API does not say which kind it is: an

approval takes Yes and No, a notice takes Acknowledged, a request for information takes

Acknowledged and sometimes Cancel. A wrong answer comes back as an error from Bitrix24, not from

the node. What a task asks for beyond the answer is in PARAMETERS.Fields of Get Many, and those

values go into Fields (JSON) of Complete.
Complete answers for the user the webhook belongs to, and only that user's own tasks.
Answering a waiting process
Event → Send Result is the other direction: a process is paused on an automation rule or an

action that waits for an outside answer, and this hands it back. It needs the event token that the

rule posted, so the parameter is filled from the workflow input, not typed in.
Those waiting rules and actions are registered by an installed application — bizproc.robot.add and

bizproc.activity.add refuse a webhook — so this pair is useful when such an application is already

on the portal. Write Log puts a line into the process log through the same token, for a long job

that wants to report progress. Both need logging switched on in the template.
Bitrix24 Lists
Universal lists: the tables a portal keeps next to the CRM — requests, contracts, registries — with

their elements, fields and sections. The webhook needs the lists permission.
| Resource | Operations |

|---|---|

| Element | Get Many, Create, Update, Delete, Get File URL |

| List | Get Many, Create, Update, Delete, Get Type |

| Field | Get Many, Get Types, Create, Update, Delete |

| Section | Get Many, Create, Update, Delete |
Naming the list
Every operation names the list twice. List Type is where it lives — universal lists of the

portal, group lists inside a workgroup, or process lists of the news feed — and then List ID or

List Code says which one. Bitrix24 refuses the call when the type does not match the list, and

List → Get Type answers the type when only the ID is known. A self-hosted portal with its own

information block types has Custom List Type for them; it needs the list named by ID or code.
Fields carry the codes
An element's values live under field codes, not names: PROPERTY951, PROPERTY1003. **Field →

Get Many** is what gives them, so a workflow that writes elements usually reads the fields first.

Those codes go into Fields (JSON) of Create and Update and into the filter of Get Many

({"=PROPERTY_951": 1269}). A field set as multiple takes an array even for one value.
Field → Create fixes the type once and for all: Bitrix24 does not change the type of an existing

field, and Update wants the type passed again unchanged. Values of a List field go in as

Values of a List Field, one per line.
Files of an element
Element → Get File URL answers the links of a File or File (Drive) field — paths on the portal

like /bitrix/tools/disk/uf.php?attachedId=103&action=download, one per value. Field ID here is

the number without the PROPERTY prefix: 951 for PROPERTY951.
Bitrix24 Catalog
The product catalog the CRM sells from: products, their variations and services, prices, sections,

properties, units, VAT rates, stores, stock and inventory documents. 148 operations across 26

resources: every one of the 145 working catalog.* methods, plus Product Image → Download,

Inventory Document → Get and Price → Set Product Prices, which Bitrix24 has no single method for. The webhook needs the catalog

permission, and crm for the currency pickers.
| Resource | Operations |

|---|---|

| Product, Variation, Product With Variations, Service | Create, Get, Get Many, Update, Delete, Get Fields, Download File |

| Product Image | Upload, Get, Get Many, Download, Delete, Get Fields |

| Price | Create, Get, Get Many, Update, Delete, Get Fields, Set Product Prices, Replace Product Prices |

| Price Type, Price Type Name | Create, Get, Get Many, Update, Delete, Get Fields (+ Get Languages) |

| Price Type Access | Create, Get Many, Delete, Get Fields |

| Markup | Get, Get Many, Get Fields |

| Rounding Rule | Create, Get, Get Many, Update, Delete, Get Fields, Get Rounding Types |

| Section, Property, Property List Value | Create, Get, Get Many, Update, Delete, Get Fields |

| Property Feature | Create, Get, Get Many, Update, Get Fields, Get Available |

| Property Filter Setting | Get, Get Many, Set |

| Unit of Measure, VAT Rate, Store | Create, Get, Get Many, Update, Delete, Get Fields |

| Unit Ratio, Stock | Get, Get Many, Get Fields |

| Inventory Document | Create, Get, Get Many, Update, Delete, Delete Many, Conduct, Conduct Many, Cancel, Cancel Many, Get Fields, Get Types, Get Inventory Mode |

| Document Item | Create, Get Many, Update, Delete, Get Fields |

| Document Supplier | Create, Get Many, Delete, Get Fields |

| Document Custom Field Value | Get Many, Update |

| Catalog | Get, Get Many, Get Fields, Is Variations Catalog |
Which catalog
A portal keeps its products in one catalog and, once a product has variations, the variations in

a second one tied to it (productIblockId of the second names the first). Catalog can be left

empty everywhere: the node takes the catalog the CRM uses, or the variations catalog tied to it.

Bitrix24 refuses a product list without it — Required filter fields: iblockId — so the node always

sends one.
Four kinds of item
Product, Variation, Product With Variations and Service are four method families of

one shape. Product → Get Many returns every kind that lives in the product catalog, told apart by

type: 1 a simple product, 3 a product with variations, 7 a service. Variations are read with

Variation → Get Many, and Parent Product ID narrows them to one product. A product with

variations has no price or stock of its own; its variations do.
Fields and properties
Fields to Return left empty reads every field and every property. The list method has no "all"

(select: ["*"] answers Required select fields: id, iblockId), so the node first asks

getFieldsByFilter for the field names — one extra call per Get Many.
Property values go into Property Values (JSON) keyed by property ID or code:

{"258": "Oak", "COLOR": ["Red", "Blue"]}. A multiple property takes an array, a list property the

ID of its value (Property List Value → Get Many with {"propertyId": 258}). A list property

with a single value is the exception: Bitrix24 treats it as a checkbox, reads it as "Y" or "N"

and takes "Y" to set it. An empty string clears a value, an empty array a multiple one. The

node sends every value as {"value": …}, the only form update takes (see

Quirks). **Property → Get

Many** gives IDs, codes and types; the field descriptions of Get Fields type every property alike,

so the property list is where a file property (propertyType F) shows. Read back, a property holds

{"value": …, "valueId": …}, or an array of those.
To find the product an outside system knows, filter Get Many by External ID: {"xmlId": "SKU-1"}.
Prices
The selling price is not a product field: a product has one price per price type. **Set Product

Prices** sets several at once: a price of a listed type is changed in place and keeps its ID, a

missing one is added, and prices you do not list stay unless Remove Other Prices is on. It

reads the current prices and makes one call per price. Replace Product Prices does it in one

call through catalog.price.modify: the product ends up with exactly the prices listed, and every

one of them gets a new ID. Purchasing Price is a product field, the price the item costs to buy in.
A new price type comes with view and buy access for the default customer groups, so **Price Type

Access → Create** for one of them answers "The specified access type for this group already exists".
Files and pictures
Download File fetches a picture or a file property of an item. Product Image → Download

fetches one image by the public link Bitrix24 gives it. Upload adds an image from binary data;

without a type it goes to the gallery (MORE_PHOTO).
Stock and inventory documents
Stock → Get Many tells what every store holds and how much is reserved, e.g. of one product

with {"productId": 101}. The API does not write stock directly. With inventory management off

(Inventory Document → Get Inventory Mode answers false), the product's Quantity field is

the stock. With it on, stock moves only through inventory documents: Create a document,

add products with Document Item → Create, then Conduct. Cancel takes a conducted

document back. status of a document is N for a draft, Y once conducted, C when cancelled. With

inventory management off, documents and their items can be created, changed and deleted, but

Conduct and Cancel answer "Inventory management has to be enabled to process inventory objects".

Suppliers and custom fields work in that mode too.
Document Supplier → Create takes a CRM company or contact from the Supplier category: the

category coded CATALOGCONTRACTORCOMPANY (or …_CONTACT) in CRM → Category → Get Many. A

custom field of documents is made per document type with CRM → Custom Field Config → Create,

module catalog, entity CATSTOREDOCUMENT_A for receipts. Document Custom Field Value then

names it field plus the ID that call answered — field287, not the UF_… code.
Bitrix24 Event Log
What the portal wrote down about itself: sign-ins, password changes and the other actions the event

log keeps. Read-only — Bitrix24 has no method that adds an entry. The webhook needs the main

permission and an administrator behind it; for anyone else every method here answers Access denied.
| Resource | Operations |

|---|---|

| Entry | Get Many, Get, Get New |

| Field | Get Many, Get |
The five methods belong to REST 3.0, which the node addresses and unwraps for you. What shows

through is the error format: it names the field it refused and why.
Only five fields can be filtered
id, timestampX, auditTypeId, userId, guestId. A condition on any of the other eight —

severity, moduleId, itemId, remoteAddr, userAgent, requestUri, siteId, description —

is not ignored but fails the whole call: severity: DTO "EventLogDto" in field "severity" requires

attribute "Filterable" to perform this request. The same five are the ones that sort, and **Field →

Get Many** says so per field in filterable and sortable.
Filter builds the usual conditions: a period, an event type such as USER_AUTHORIZE, a user.

Extra Conditions (JSON) takes the REST 3.0 form as it is — an array of ["field", "operator",

value] triples, e.g. [["timestampX", ">=", "2026-09-01T00:00:00+03:00"]].
Dates go in as ISO 8601 down to the second. Milliseconds are refused, and a date built in

JavaScript carries them, so the node cuts them off before the call.
Get Many reads a period, Get New polls
Get Many is the report: a period, a sort order, and paging done for you up to Limit or to

everything. Get New is the poll — it takes the ID the previous run stopped at and answers what

appeared after it, so a schedule reads every entry once and none of them twice. The ID grows with

every entry and never repeats; a time can be the cursor instead when the order of writing matters

less than the order of events.
Bitrix24 Consents
The agreements a portal keeps and the consents people give to them: personal data, newsletters,

terms of use. The webhook needs the userconsent permission, and any user may call these methods.
| Resource | Operations |

|---|---|

| Agreement | Get Many, Get Text |

| Consent | Create |
Agreements themselves are written and edited in the Bitrix24 interface — the API has no Create or

Update for them, only the three methods above.
Collecting a consent takes three steps
1. Agreement → Get Many finds the agreement by name and tells whether it is switched on:

   ACTIVE is N for a disabled one, and a disabled agreement should not be shown.

2. Agreement → Get Text returns TEXT to display and LABEL for the button.

3. Consent → Create stores the answer against the agreement ID and the IP address it came from.

   It answers the ID of the record.
The form is yours. Bitrix24 hands out the wording and keeps the record; it displays nothing and

asks no one. IP Address is required — Bitrix24 stores whatever it is given and does not check it.
Substitutions fill a standard agreement, the kind made from a Bitrix24 template: the company

name and address, the purpose, the third parties, an e-mail, the button caption. An agreement

written by hand holds arbitrary HTML and ignores them.
A consent, once written, stays: no REST method deletes one.
Bitrix24 AI
The AI services a portal sends prompts to. This node connects a service of your own and lists what

is connected; it runs no prompt. Bitrix24 calls the service itself, when a person uses AI in a CRM

card, a chat or an automation rule. The webhook needs the ai_admin permission and an

administrator behind it.
| Resource | Operations |

|---|---|

| Service | Get Many, Register, Unregister |
Register takes a code, a category — text, image, audio or call — and the address of an

endpoint you host. Bitrix24 checks that address before it saves anything: it has to answer 200.

Afterwards Bitrix24 posts prompts to it with a callbackUrl and an errorCallbackUrl, and expects

an answer within five seconds — 200 with the result, or 202 and the result posted to the

callback later. The link has a lifetime, in ttl, after which the person sees nothing. An image

service has to work that asynchronous way.
Settings carries what the service code reads: the model alias shown next to it, whether context

is counted in tokens or symbols, and the context limit.
Unregister removes a service by its code and answers false, not an error, when there was

nothing to remove.
Bitrix24 Trigger
Starts a workflow when Bitrix24 posts an outgoing webhook.
1. In n8n, copy the trigger's Production URL.

2. In Bitrix24, Developer resources → Other → Outgoing webhook: paste the URL, tick the

   events, save.

3. Copy the Application token Bitrix24 shows into the trigger.
It has to be done by hand. The method that would subscribe the URL automatically, event.bind,

answers WRONGAUTHTYPE to inbound webhooks: only an installed application may call it.
Requests without the right application token get 403 and never start the workflow, and the

token is removed from the output. The Events list has 196 event codes from the

documentation, the catalog's CATALOG.PRODUCT.ON.ADD and the like among them; codes it lacks go

into Other Event Codes. Events not selected are answered OK and dropped.
The five chat events ONIMV2… are in the list, but an outgoing webhook never delivers them:

Bitrix24 keeps them in the event queue of the user who subscribed, and they are read from there

by the Bitrix24 Messenger Trigger. The list says so under each of

them.
Bitrix24 sends only IDs, for example data.FIELDS.ID on ONCRMDEALUPDATE. **Fetch the Changed

CRM Record** reads the whole lead, deal, contact, company, quote or smart process item after an

add or update event and puts it under record. If that read fails, the workflow still starts,

with the reason in recordError.
Bitrix24 Messenger Trigger
Starts a workflow on new, edited or deleted messages, reactions and new members in the chats of the

webhook user. It polls Bitrix24's event queue on n8n's schedule, so it works on an n8n without a

public address and needs no setup in Bitrix24.
On activation it subscribes the webhook user and skips whatever is already queued, so turning the
  workflow on does not replay the last day.
Dialog IDs narrows it to some conversations: chat123 for a group chat, a user ID for a
  private one.
The webhook user's own messages and reactions are dropped unless Include Own Events is on, so a
  workflow that answers in the same chat does not start itself.
A manual test run reads what is queued without confirming it; the active workflow still gets it.
Bitrix24 keeps one queue per user. A second workflow, or another application reading the same user,

takes events away from this one: use a separate webhook user per listener. Deactivating the workflow

does not unsubscribe; Messenger → Event Queue → Unsubscribe does.
An edit made through the REST API did not reach the queue, while new messages, reactions and

deletions did. Edits made in the Bitrix24 apps were not tried.
Bitrix24 Chatbot Trigger
Starts a workflow on messages to a bot, slash commands and button presses, reactions to the bot's

messages, the bot being added to a chat, and a chat opened through a link with BOT_CONTEXT data.

It polls the bot's event queue on n8n's schedule, so it works on an n8n without a public address.
Events defaults to New Message and Command Called.
On activation it checks that the bot keeps its events for polling, and fails with the reason if the
  bot posts them to a URL instead. Then it skips whatever is already queued, so turning the workflow

  on does not answer a backlog.
Messages, commands and reactions of bots, the bot itself included, are dropped unless **Include
  Events From Bots** is on. Two bots in one chat cannot talk to each other forever that way.
Dialog IDs narrows it to some conversations.
A manual test run reads what is queued without confirming it.
Each event is one item: eventId, type, date, and the event's own data — message, chat,

user, and command or reaction where they apply. Bitrix24 keeps one queue per bot: a second

workflow reading the same bot takes events away from this one.
Rate limits
Bitrix24 has two limits, and they punish different things.
Requests per second. 2 per second on most plans and 5 on Enterprise, as a leaky bucket

with a burst of 50 (250 on Enterprise), counted per portal and per source IP. Every

workflow on one n8n instance shares it, so the nodes queue requests per portal. Over the limit,

Bitrix24 answers QUERYLIMITEXCEEDED before running anything, and the node retries that

with backoff.
Execution time. Each method has a budget of server time per ten minutes, per webhook. The

exact figure is set by Bitrix24 per portal; the documentation's own example uses 480 seconds. Past that, the method answers OPERATIONTIMELIMIT for up to ten minutes for

everyone using that webhook. The node does not wait that out; it fails with the reason. Heavy

filters, select: ["*"] on large lists and offset paging burn this budget. A separate webhook

per integration keeps one runaway workflow from blocking the others.
Quirks worth knowing
methods misses every controller method: crm.item., tasks.task., catalog.* are absent
  from it and work fine.
method.get compares in lower case and says booking.v1.resourceType.list does not exist,
  though calling it works. Check Method lower-cases the name before asking.
REST 3.0 method URLs have no .json suffix. With it, the answer is 404.
The default deal pipeline has ID 0, so pipeline operations accept 0 where other IDs must be
  positive.
Custom boolean fields are filtered with 1 and 0, though they are read and written as Y
  and N.
Timeline comments want the entity type as a word (deal, dynamic_1234), product rows as a
  short code (D, T4d2 for smart process 1234), and most other methods as a number. The

  nodes take the number everywhere and convert.
Errors with an empty error code are normal: method-level failures often carry only
  error_description. The node shows both when there are both.
A timeline log entry written through a webhook cannot be deleted through one:
  REMOVING_DISABLED, only the application that wrote it may. Write log entries you will want

  to remove as comments instead.
Requisites attach to a deal only once the deal has its client set: otherwise
  Requisite with ID … can not be tied to the Deal in which the client is not selected.
A pipeline can be deleted while its deleted deals still sit in the recycle bin.
A recurring deal template is created active even with ACTIVE: N. Its setting cannot be
  deleted once a deal was made from it, even a deleted deal: Connected recurring deal exists.

  Deleting the template deal removes the setting with it.
crm.item.delivery.list returned nothing for a shipment added through sale.shipment.add,
  while Get by ID read it. The documentation has since explained it: the list leaves out system

  shipments and shipments without a delivery service, Get by ID does not. Only deals and invoices

  have deliveries; for any other type the list is empty.
A payment updates only paySystemId and paid; anything else answers Empty fields.
Product Row → Update sends only the fields that are filled in, and Bitrix24 keeps the rest and
  recounts the record's total. Up to 0.11.0 it sent a price of 0 and a quantity of 1 whenever those

  two were left alone, so changing only a discount or a tax zeroed the row.
Product Row → Replace All writes every row whole: a row without a price costs 0, even with a
  catalog Product ID. Every row comes back under a new ID. The documentation says a row sent with

  its id keeps it; on a live portal id as a number, as a string and ID all gave a new row.

  Update is the way to change a row and keep its ID.
The documentation says the product row list filters by id and productId only, and returns
  every row of the record for a condition on anything else. Filters → Product ID in Get Many

  uses the one that matters.
Payment → Create makes an empty payment: rows are put in with Add Product. A quantity there is in
  whole units, and Bitrix24 drops a fraction without an error: 1.5 in Add Product and in Set Product

  Quantity was stored as 1. An entry put in by Add Product lists entityId, not rowId, and stayed

  in the payment after Replace All took its row away.
A digital workplace created with typeIds came back with none attached.
A pipeline without its own card layout returns null: the built-in layout is not readable.
Call lists cannot be deleted through the API.
Create and Update start the business processes set to run when a record is created or changed,
  as saving in Bitrix24 does.
A file field of a CRM record comes with urlMachine, a download link that for a webhook holds the
  webhook code. Up to 0.4.1 the CRM node and the trigger's Fetch the Changed CRM Record passed

  it on; since 0.5.0 every node replaces any value holding the webhook code with

  [removed: it contained the webhook secret].
Tasks and workgroups:
Request to Join from someone already in the group takes them out of it, and the answer
  is true. Tried on the owner: after the request the group had no members at all. The node

  refuses the request for a member.
The node also refuses to Remove an owner: move ownership with Set Owner first. What
  Bitrix24 itself does with that request was not tried on a group that still had its owner.
Add, Invite and Set Role on the owner answer an empty list and change nothing.
Approve and Return for Rework need two people. On a task whose creator is also its responsible
  user, control is skipped: Complete goes straight to completed, and both answer

  Action unavailable.
On a task with time tracking, Start and Pause write time entries by themselves.
Time Entry → Get Many across all tasks includes entries of deleted tasks; Get on those answers
  Task not found or not accessible.
A dependency lives on the dependent task: after Dependency → Create from A to B, Get Many of B
  lists A and Get Many of A is empty.
A kanban stage that still holds tasks is not deleted: NO_EMPTY. The first stage of a group
  kanban is a system one and is never deleted: IS_SYSTEM.
A file attached to a task in a group is copied to the group's Drive, and a group with files on
  its Drive cannot be deleted: DISKNOTEMPTY.
Flow → Update resets settings the request leaves out: the flow's template went back to 0.
  Toggle Pin answers the new state, pinned: true or false.
A sprint needs start, end and status (Incorrect dateStart format, Incorrect sprint status
  otherwise) and the user who creates it: without createdBy Bitrix24 answers Unable to add

  sprint and names no reason. Until 28.09.2026 the documentation showed the field in its examples

  only. Sprint → Create fills in the user the webhook acts as unless Created By User ID says

  otherwise.
tasks.api.scrum.sprint.get takes id. Until 28.09.2026 its documentation listed sprintId,
  which Bitrix24 answers with Could not find value for parameter {id}.
The documentation says a sprint starts only with at least one unfinished task in it and no
  other sprint of the scrum active, and that starting and completing need the scrum owner, a

  moderator or an administrator.
A task created in a scrum group lands in the scrum backlog by itself. A task from outside the scrum
  cannot be brought in by Scrum Task → Update: without a backlog or sprint Bitrix24 answers Entity id

  not found, and with the backlog of the scrum ERROREMPTYENTITY_ID.
Sort on a scrum task sets the fractional order sortFloat to the same number; a sortFloat of
  2.5 turns sort into 3.
A group created through the API can come out as a collab with the scrum master dropped. Make a
  scrum in Bitrix24 itself; epics and backlogs work on a collab anyway.
The epic and sprint lists take field names in upper case in their filters: GROUP_ID, NAME. A
  field spelled any other way, groupId included, gives an empty list and no error. Up to 0.10.2

  Scrum Epic → Get Many sent groupId, so with a scrum picked it found nothing.
The epic and sprint lists answer neither next nor total, only pages of 50. Get Many asks for
  the next 50 while a page comes back full; up to 0.10.2 Return All stopped after the first 50.
Scrum Epic → Get with Include Files off sends withFiles: false. The strings "false" and
  "N" still bring the files back.
Time is logged only for the person who spent it: the documentation says Bitrix24 refuses any
  author but the webhook user. Started At and Stopped At are stored as given and do not

  change the time spent: an entry of 600 seconds with an hour between them kept 600. A date without

  an offset is read in the Bitrix24 time zone. Time Entry → Update sends the comment every time, and

  an empty one clears it.
The ID of a message in the task chat is not in the task history; a result from a chat message
  needs the ID from Bitrix24 Messenger → Message → Get Many or from MESSAGE_ID of the Task

  Comment Added trigger event.
tasks.task.add once answered with an internal PHP error
  (Workgroup::getUserMemberIds(): Return value must be of type array) for a group whose owner

  had been taken out by Request to Join, and saved the task all the same.
Messenger and open lines:
The download link Bitrix24 gives a webhook (im.v2.File.download) contains the webhook code in
  its path. Anything that prints it hands the secret over, which is why the node has no Get Download

  Link.
Tags on notifications (TAG, SUBTAG with CLIENTID) are ignored through a webhook: a second
  notification with the same tag did not replace the first, the tag was not stored, and Delete by

  tag answered true and removed nothing.
Get IDs of chat members (im.chat.user.list) answers ACCESS_ERROR on the company-wide general
  chat even for its members; Get Many (im.dialog.users.list) works there.
A chat cannot be deleted through the API, only left. A system message in it cannot be deleted
  either: CANTEDITMESSAGE.
An edit through im.message.update did not produce ONIMV2MESSAGEUPDATE in the event queue
  within 12 seconds; the send, the reaction and the deletion around it did.
Reading messages, notifications and recent chats did not change unread counters.
imconnector.* does not work with webhooks at all (stated in the documentation), so custom
  open channel connectors need an application.
Drive:
disk.storage.getForApp answers Application context required to a webhook, and
  disk.storage.rename on a personal drive answers Access denied (invalid type of storage) with an

  empty error code. Both are for application storage, so the node has no operations for them.
Errors with an empty code happen on Drive too: check error_description, not only error.
Calendar:
A weekly rule with no weekday is stored as Monday, whatever day the event starts on, and the
  event then never comes back from calendar.event.get: created, readable by ID, missing from

  every list. The node names the weekday of the start instead.
calendar.event.getNearest, as the overview page of the documentation spells it, does not
  exist: the method that answers is calendar.event.get.nearest.
The period of calendar.event.get is open at its end, so the same day in from and to
  returns nothing, and a one-day event needs a to past it.
from and to are read as ISO dates. A day written the way the portal prints dates,
  16/09/2026, is not understood and quietly widens the period by years instead of failing.
Dates in an answer are text in the portal's own format, not ISO; DATEFROMTS_UTC and
  DATETOTS_UTC are the timestamps to compare.
calendar.event.getbyid answers an empty object, not an error, for an event that was deleted.
  The node turns that into Bitrix24 has no event .
The meeting-status methods need an event that is a meeting. On an event with no participants,
  calendar.meeting.status.get answers Error while retrieving status and

  calendar.meeting.status.set answers true without storing anything.
calendar.accessibility.get lists only what takes up time: an event whose accessibility is
  free is not in it.
calendar.user.settings.set keeps the keys it is not given: writing one flag left every other
  setting of a live account untouched.
Employees, structure and working time:
user.get and user.search take their filter flat, in the body itself, not inside a filter
  object. The same goes for department.get.
Both leave out bots, mail users, extranet users and Open Channel accounts, so those IDs simply
  return nothing.
A custom field of the employee card is stored under UFUSR plus the upper-cased code, and that
  longer name is what every read returns.
timeman.record. and the whole humanresources. group answer ERRORMETHODNOT_FOUND on a
  portal that does not have the newer org structure, so the node has no operations for them.
timeman.timecontrol.settings.get answers in lower case (minimumidlefor_report) while
  settings.set takes upper case (MINIMUMIDLEFOR_REPORT). In the same settings ACTIVE: false

  does not switch the module off — only 0 does, which is what the node sends.
A working day cannot be removed once written: there is no delete method for a timesheet entry.
timeman.networkrange.set replaces the whole list of office ranges and answers false with the
  ranges it did not understand, rather than an error.
Chatbots:
A bot's chat background cannot be reset to each person's own once it is set. The documentation
  says null resets it and an unknown value becomes null; in practice null, an empty string

  and an unknown value all left it as it was. The node offers no reset.
imbot.v2.Command.list returns the messenger's built-in commands (/me and others, bot ID
  0, IDs like def0) together with the bot's own. Command → Get Many leaves them out unless

  Include Built-In Commands is on.
A system line the bot sent (authorId 0) cannot be deleted by the bot, and not by the chat owner
  either: CANTEDITMESSAGE.
Chat → Create answers with users holding the bot alone, even when members were added; Chat
  Member → Get Many lists them. Chat → Update works only in a chat the bot owns, whatever the chat's

  permission settings say.
A first message given to imbot.v2.Chat.add is not written: two chats made with and without it
  held the same two service lines. The documentation dropped the parameter on 28.09.2026. Since

  0.11.1 First Message is posted by the bot right after the chat is made, and its ID comes back

  as firstMessageId; up to 0.11.0 the chat was created without it.
The same reaction twice is REACTIONALREADYSET, not a quiet success.
The bot's own edits reach its own queue as Message Edited events, unlike REST edits in the
  messenger queue. The trigger drops them with the other bot events.
In a response with no forwarded messages, uuidMap is an empty array; the node turns it into an
  empty object, the shape it has with forwards.
Business processes and lists
A new list field needs a code. lists.field.add answers ERRORSAVEFIELD, "Please fill the

code fields", without one, although the documentation marks CODE optional. Field → Create has

it as a required parameter for that reason.
Two business process list methods answer almost nothing by default.

bizproc.workflow.template.list returns rows of ID alone when no field list is given, and

bizproc.workflow.instances returns ID, MODIFIED and OWNED_UNTIL. Left empty, **Fields to

Return** therefore sends the usual fields rather than nothing.
A workflow ID is a string. bizproc.workflow.instances answers IDs like

66e412fdc9bd44.36306599, 23 characters; Terminate and Delete take that string, whatever the

documentation says about the type of bizproc.workflow.kill.
Only a process that is still waiting can be stopped. A process whose template runs straight

through is over before the next request arrives, and Terminate and Delete then answer "The business

process is not found" rather than a success. Both were checked on a process waiting for a decision:

there they answer true and the process leaves Get Instances at once.
Catalog
File fields are named the way the links spell them. catalog.product.download and its variation,

parent and service twins take detailPicture, previewPicture or property258 in fieldName.

The documented DETAILPICTURE and PROPERTY258, and a property code, answer "Name file field is

not available". Download File sends the working form whichever way the field is given.
The download link of a product image does not work through a webhook. catalog.productImage.get

hands out downloadUrl as /rest///download/?token=…: it carries the webhook

secret, and fetching it answers ERRORMETHODNOT_FOUND. The node keeps it out of every output and

downloads from detailUrl, the public link of the same file.
A list wants its keys. Product, variation and service lists answer Required select fields: id,

iblockId without both in the field list, and Required filter fields: iblockId without the catalog

in the filter; catalog.section.list wants the catalog too. The node adds all three.
A property value on update must be wrapped. catalog.product.update takes {"property258":

{"value": "Oak"}}. Given a bare "Oak", a text property keeps its old value and a number

property is cleared, and the call still answers success. Add takes both forms; the node always

wraps.
catalog.price.modify refuses existing prices. Any price that names its ID — as a number, as

a string, with every field of its row — answers "Validate price error. Catalog price group is

wrong", although the documentation shows exactly that. Without IDs the method replaces the whole

set. That is why Set Product Prices goes price by price and Replace Product Prices says what

it does.
A VAT rate wants its name on every update. catalog.vat.update without name answers

"Required fields: name", even when only the rate changes.
Custom field values want documentType in the field list. catalog.userfield.document.list

with a field list that lacks it answers "The documentType field is not specified in the select

parameter". Up to 0.10.1 Document Custom Field Value → Get Many passed Fields to Return as

given and failed this way; the node now adds documentType itself.
Event log, consents and AI
A filter on the wrong field of the event log fails the call. Only id, timestampX,

auditTypeId, userId and guestId are filterable and sortable; a condition on severity or on

any of the other seven answers DTO "EventLogDto" in field "severity" requires attribute

"Filterable" to perform this request. Nothing is silently dropped, which is the pleasant half of it.
The event log refuses milliseconds. 2026-09-01T00:00:00Z and 2026-09-01T00:00:00+03:00 are

taken, 2026-09-01T00:00:00.000Z is not, and neither is a bare date. The node cuts the

milliseconds a JavaScript date carries; an expression that builds the string itself should do the same.
Substitutions only reach a standard agreement. userconsent.agreement.text fills the company

name, the purpose and the button caption into an agreement made from a Bitrix24 template. An

agreement written by hand is arbitrary HTML, and the replace values are ignored without a word.
A consent cannot be unwritten. userconsent.consent.add has no counterpart: the record stays.
Application storage and message providers refuse a webhook. Every method of entity.* (17) and

messageservice.* (5) answers ACCESS_DENIED Access denied! Application context required, so

neither has a node here. They wait for the OAuth2 credential of a local application.
What was checked
Against a live Bitrix24 portal, 14.09.2026, through a harness that runs the compiled nodes with

a fake n8n context. Reads went through as they are; writes went only to objects the run created or

left settings as they were, and everything the API can delete was deleted at the end.
| | Operations |

|---|---|

| Write, checked | 137 |

| Read, checked | 123 |

| Works, with a Bitrix24 limitation | 17 |

| Not checked | 0 |
The live runs found four bugs in the node, fixed before this version: crm.currency.update

takes ID where every other currency method takes id; userfieldconfig.add and

update take field, not fields; adding a product to a payment needs quantity; and

a payment accepts only paySystemId and paid on update.
On 15.09.2026, after Bitrix24 rebuilt its page on CRM fields, three more runs checked what the

page says about writing fields and found three bugs, fixed in 0.4.1. The mapper offered contacts and companies, which fail on write. Import

failed whenever phones or emails were given. And the node's own hint said an existing phone could

be changed through its ID in fm, which Bitrix24 ignores: the phone was added a second time.
On 23.09.2026 Bitrix24 rewrote its pages on product rows, and the new line "pass only the fields

that have to be changed" showed that Product Row → Update reset the price to 0 and the quantity to

1 whenever those two were left alone. Fixed in 0.11.1 and checked on 29.09.2026 by two runs on a

deal of their own: Update with only a tax name, only a discount or only a price, Tax Name, the Product ID filter

of Get Many. The same runs found that Replace All gives every row a new ID whatever the

documentation says, that a payment quantity loses its fraction, and that Payment → Create makes an

empty payment, where the node's description had said it covers the record's products.
The tasks node was checked the same way, on tasks, a custom field, workgroups, flows, templates,

My Plan stages and files the run created and deleted at the end.
| Bitrix24 Tasks | Operations |

|---|---|

| Write, checked | 73 |

| Read, checked | 38 |

| Works, with a Bitrix24 limitation | 18 |

| Not checked | 0 |
The scrum operations waited until 23.09.2026 for a scrum: the API makes a collab instead. They ran in

a hidden scrum made in the Bitrix24 interface, with the webhook user alone in it, on sprints, a

kanban stage, an epic and tasks the run created and deleted. That run found two bugs, fixed in

0.10.1: Sprint → Create never worked, as Bitrix24 refuses a sprint without its author, and Sprint →

Get sent the parameter name from the documentation, which the method does not know.
On 26.09.2026, after Bitrix24 rewrote its pages on epics and time entries, a run in the same scrum

on two epics, a task and two time entries found that Epic → Get Many with a scrum picked found

nothing, and that Return All on epics and sprints stopped at 50. Both are fixed in 0.11.0, and

Include Files, Move to Scrum ID and the dates of a time entry were checked there too.
Those runs changed the node before this version: Request to Join refuses a member (Bitrix24

takes the member out instead), Remove refuses a group owner, Sprint → Create requires start, end

and status, Dependency → Get Many says which task holds the link, and Toggle Pin answers the

state instead of a success flag.
The messenger node wrote into a chat the run created: messages, edits, likes, files, marks, pins,

the event queue; notifications and the user status were checked too. The harness checked every

output for the webhook code. At the end everything the API can delete was deleted.
| Bitrix24 Messenger | Operations |

|---|---|

| Write, checked | 29 |

| Read, checked | 23 |

| Works, with a Bitrix24 limitation | 5 |

| Not checked: they change all of a user's chats, post to the feed or need a second person | 6 |
The open lines node read line settings, CRM chats and statistics, and created, changed and deleted

a line of its own. Dialogs, operator actions, CRM chat writes and bot dialogs need a conversation

with a client, so they were not run.
| Bitrix24 Open Lines | Operations |

|---|---|

| Write, checked | 3 |

| Read, checked | 11 |

| Not checked: they need a conversation with a client | 29 |
Those runs changed the messenger node before this version: Get Download Link was removed because

the link carries the webhook code, and notification tags were removed because a webhook cannot use

them. The Message Edited option of the trigger now says that REST edits did not arrive.
The Messenger Trigger was run on the same chat: the first poll skips what is queued, a manual run

confirms nothing, the dialog filter and the own-message filter work.
The chatbot node was checked on 15.09.2026 with two bots the run registered, a plain one and a

supervisor, in a group chat the bot created. The events came from private messages, a message with

and without a mention, a typed command, a button press, a like, an edit and a chat opened with

context. At the end the messages, the command and both bots were deleted. Every output was checked

for the webhook code and for the bot token.
| Bitrix24 Chatbot | Operations |

|---|---|

| Write, checked | 21 |

| Read, checked | 7 |

| Works, with a Bitrix24 limitation | 6 |
The same run pressed a bot button through Bitrix24 Messenger → Message → Run Bot Command, which

had waited for a bot since 0.3.0. The Chatbot Trigger was run on the plain bot: the delivery mode

check, skipping the queue on activation, a manual run, the dialog filter, dropping bot messages and

not delivering an event twice. Its refusal of a bot in webhook mode was checked on a faked answer.
Those runs changed the chatbot node before this version: the background reset option was removed,

Command → Get Many filters out built-in commands, and Send without forwards returns an empty object.
The Drive node was checked on 15 and 16.09.2026 on folders and files the run created: text files

and a 10 MB file of random bytes, new versions, copies, the trash, public links, sharing and access

rights, and moving and copying to the drive of a workgroup the run created. Other drives were only

read. Everything was deleted for good at the end. The date conversion was also checked offline for

a user without a time zone, winter time and date-only values.
| Bitrix24 Drive | Operations |

|---|---|

| Write, checked | 16 |

| Read, checked | 17 |

| Works, with a Bitrix24 limitation | 3 |
The limitations: File → Move and Folder → Move work within one drive only, and Get Versions shows

only the latest contents.
Those runs changed the node before this version: Updated After converts dates to the webhook

user's time zone, since Drive matched nothing with an offset; the Filter (JSON) hints show plain

arrays instead of the @ prefix Drive ignores, and name the fields a filter can use; version

descriptions no longer promise that older contents are kept. They also found that a CRM file field's urlMachine carries the

webhook code, which the CRM node had been putting into its output since 0.1.0: every node now

removes such values. If executions with CRM records that have files were shared or exported, make a

new webhook and delete the old one.
The calendar node was checked on 16.09.2026, all 21 operations, in a calendar the run created for

the webhook user: plain, all-day and repeating events, a calendar renamed and deleted, booking

resources, and the user settings written back exactly as they were read. No event had participants

or CRM links, so nobody was invited or notified. Everything created was deleted at the end.
| Bitrix24 Calendar | Operations |

|---|---|

| Write, checked | 15 |

| Read, checked | 3 |

| Works, with a Bitrix24 limitation | 3 |
The limitations are the two meeting-status operations, which need an event that is a meeting, and

Get Availability, which counts only events that take up time.
That run found the weekly recurrence bug, fixed before this version: an event repeating weekly with

no weekday picked was stored by Bitrix24 as repeating on Monday and then never came back from

calendar.event.get — created, readable by ID, missing from every list. The node now names the

weekday the event starts on. The same runs mapped the edges of the period Get Many reads, and which

date formats Bitrix24 understands there.
Besides the live runs, 26 offline checks read the request each operation builds: the dates and the

time zone that go with them, the all-day form, the recurrence rule, the participant list turning an

event into a meeting, the two ways of filtering bookings, and the settings Bitrix24 spells as Y

and N.
The employees node was checked on 16.09.2026: 20 reading operations against the portal as it is,

and the writing ones on the webhook user alone — a department created for the run with nobody in it, a custom

field of the run, one harmless field of that user's own card with the value put back, and that

user's own working day opened, paused and closed. The two portal settings were written back exactly

as they had been read. No other employee was touched.
| Bitrix24 Employees | Operations |

|---|---|

| Write, checked | 6 |

| Read, checked | 16 |

| Works, with a Bitrix24 limitation | 7 |

| Not checked: an invitation emails a real person; explaining an absence needs the time control module switched on with an absence already recorded; a work schedule ID is only visible in the portal interface | 3 |
The seven with a limitation are the ones that could only be checked on the webhook user itself or

written back unchanged: Update of a card, the three working-day operations, the time report of that

one person, and the two portal settings. Their code is the same whoever it runs for, but a live

check on somebody else would have meant changing somebody else's data.
Besides that, 23 offline checks read the request each operation builds: the flat filter, the field

list, dismissal as ACTIVE: N, ATOM times for the timesheet, the settings Bitrix24 spells in two

cases at once, and the refusals the node makes on its own.
The lists node was checked in full on a list the run created and deleted: fields of two types, a

section, an element with a number and a file, the filter by field code, the file link, and the

deletions in the order Bitrix24 allows. Nothing outside that list was written.
| Bitrix24 Lists | Operations |

|---|---|

| Write, checked | 12 |

| Read, checked | 7 |

| Not checked | 0 |
The business process node was checked on a deal the run created in its own pipeline, with a template

made for the test: a manual start on deals, a comment and then a decision the process waits for.

Three processes were started on that deal — one answered through Task → Complete, one stopped

with Terminate, one removed with Delete — and each time Get Instances confirmed what

happened. The comment the template leaves on the deal is the proof a process really went through.
Left unproven: Task → Delegate, which hands work to a second person, and Event → Send Result

and Write Log, which need the event token only a rule registered by an installed application

receives.
| Bitrix24 Business Processes | Operations |

|---|---|

| Write, checked | 4 |

| Read, checked | 3 |

| Not checked: a second person, and an application's event token | 3 |
The catalog node was checked against a live portal on 19.09.2026: reads as they are, writes on

objects the run created and deleted, every write read back.
| Bitrix24 Catalog | Operations |

|---|---|

| Write, checked | 62 |

| Read, checked | 81 |

| Not run through: conducting and cancelling documents, which move stock | 4 |

| Not checked | 1 |
Linking a supplier to a receipt, removing the link and setting a document's custom field waited

until 23.09.2026: they need a CRM company of the Supplier category and a custom field of receipts,

and the run made both, then deleted them. Not checked: reading one markup, since the API cannot

create one to read.
The event log, consents and AI nodes were checked on 22.09.2026. Every operation of the event log

node ran — it has no write to run — against the log of a live portal: the field list, a period, the

cursor of Get New, paging over a page boundary, and the refusal a filter on severity gets. The

consents node read the agreements and the text of one. The AI node listed the services registered

on the portal, with and without a filter.
| Bitrix24 Event Log, Consents, AI | Operations |

|---|---|

| Read, checked | 8 |

| Not checked: a consent no method can delete, and a service that needs an endpoint of your own | 3 |
Not checked, and why: Consent → Create writes a record REST cannot remove; **Service →

Register** needs an endpoint that answers 200 to Bitrix24 and would offer the service to everyone

on the portal; Service → Unregister had nothing to remove. Substitutions in **Agreement → Get

Text** were not seen filled in either: that takes an agreement made from a Bitrix24 template, and a

hand-written one ignores them.
The trigger was fed hand-made deliveries (10 checks, including a wrong token and proto

keys) and fetched a deal. A delivery from Bitrix24 itself needs an n8n with a public

address. Offline, every operation runs with sample parameters, and every method the nodes call

exists in the documentation.
What is not here yet
Nodes for telephony, the online store (orders, payments, deliveries), sites, booking, mail, the
  activity stream and BI. Until then, the Bitrix24 node calls their methods directly.
In the business process node: automation rules, actions and templates cannot be created,
  changed or even listed — bizproc.robot., bizproc.activity. except the log, and

  bizproc.workflow.template.add/update/delete all answer ACCESS_DENIED Application context

  required to a webhook. They need the OAuth2 credential of a local application.
RPA, the 30 methods of rpa.*: Bitrix24 moved the whole section to the outdated part of its
  documentation, so there is nothing to wrap.
The newer humanresources.* org structure, 24 methods Bitrix24 is moving departments to. A
  portal without it answers ERRORMETHODNOT_FOUND, so there was nothing to check them against.
In the calendar node: clearing the participants of a meeting in one step, which needs a meeting
  flag with an empty list (Method → Call does it), and handing an event over to another

  organizer, which Bitrix24 has no method for at all.
A chatbot trigger for bots that post their events to a webhook URL. The polling trigger covers
  every event; a webhook one would save the polling delay on an n8n with a public address.
In the Drive node: switching a public link off and listing the trash, which the API cannot do;
  application storage, which needs an application; uploading through the uploadUrl Bitrix24 can

  hand out for big files, instead of base64 inside the request.
In the CRM node: changing or deleting one phone, email or messenger of a record. crm.item.update
  cannot do it; until an operation over the older per-entity methods exists, Method → Call does

  (see Fields come from the portal).
In the tasks node: legacy task comments (task.commentitem.*, gone from the new task card) and a
  trigger read of the changed task like the one the trigger does for CRM records.
Application data storage (entity.*, 17 methods) and SMS and message providers
  (messageservice.*, 5). Both sections answer ACCESS_DENIED Application context required to

  a webhook, all of them, so there is nothing a webhook credential could do with them.
An OAuth2 credential for a local application, and with it everything Bitrix24 reserves for
  applications: event.bind, custom automation robots, placements, open-channel connectors,

  and the two sections above.
Timeline layout blocks, icons and logos, configurable activities and activity badges, which


  only make sense inside an application.
Feedback and bugs
GitHub issues. Issues are public:

remove the webhook token and client data from anything you paste.
License
MIT. Bitrix24 is a trademark of its owner; see the trademark note in the licence.

Included Nodes

Description

@zenland-dev/n8n-nodes-bitrix24

Installation

Credentials

Bitrix24 Chatbot Webhook API

Bitrix24 node

Bitrix24 CRM

Fields come from the portal

Create runs automation, Import does not

Get Many reads by ID

Bitrix24 Tasks

Two APIs under one node

Comments are chat messages now

Statuses

Get Many reads by ID

Bitrix24 Messenger

Dialog ID

Sending

Reading

Files

Event Queue

Bitrix24 Open Lines

Bitrix24 Chatbot

Getting a bot going

Bot types

Buttons and commands

Events and files

Bitrix24 Drive

Where a file goes

Upload and download

Trash, versions and search

Filters

Bitrix24 Calendar

Whose calendar

Time zones

Participants and answers

Recurring events

Resource booking

Settings

Bitrix24 Employees

Turning a person into an ID

Writing to people

Company structure

Working time

Bitrix24 Business Processes

Naming the record

Starting and stopping

Tasks of a process

Answering a waiting process

Bitrix24 Lists

Naming the list

Fields carry the codes

Files of an element

Bitrix24 Catalog

Which catalog

Four kinds of item

Fields and properties

Prices

Files and pictures

Stock and inventory documents

Bitrix24 Event Log

Only five fields can be filtered

Get Many reads a period, Get New polls

Bitrix24 Consents

Collecting a consent takes three steps

Bitrix24 AI

Bitrix24 Trigger

Bitrix24 Messenger Trigger

Bitrix24 Chatbot Trigger

Rate limits

Quirks worth knowing

Business processes and lists

Catalog

Event log, consents and AI

What was checked

What is not here yet

Feedback and bugs

License

More in Communication