@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.

| Resource | Operations | |---|---| | Method | Call | | Batch | Execute Commands, Call for Each Item | | Portal | Get Permissions, Get Methods, Check Method, Get Current User, Get Server Time, Get Access Names |

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.

| Resource | Operations | |---|---| | Lead, Deal, Contact, Company, Quote, Invoice | Create, Get, Get Many, Update, Delete, Get Fields, Import, Merge | | Smart Process Item | the same, for any smart process picked from a list | | Product Row | Add, Get, Get Many, Update, Replace All, Delete, Get Fields, Get Available for Payment | | Activity | Create To-Do, Update To-Do, Set Deadline, Set Description, Set Responsible, Set Color, Complete, Get, Get Many, Delete, Get Fields, Get Call Transcript, Link to Record, Unlink From Record, Get Links, Move | | Timeline Comment | Create, Get, Get Many, Update, Delete | | Timeline Note | Save, Get, Delete | | Timeline Log Entry | Create, Get, Get Many, Delete | | Timeline Entry | Link to Record, Unlink From Record, Get Links, Pin, Unpin | | Linked Contact | Add, Remove, Get Many, Replace All, Remove All (on leads, deals, quotes, companies) | | Linked Company | the same, on contacts | | Duplicate | Find by Phone or Email, Get Extra Search Fields, Get Addable Search Fields, Add Search Field, Remove Search Field | | Pipeline | Create, Get, Get Many, Update, Delete, Get Fields | | Reference Book | Create, Get, Get Many, Update, Delete, Get Fields, Get Reference Books, Get Book Entries | | Smart Process Type | Create, Get, Get Many, Update, Delete, Get Fields, Get by Entity Type ID | | Custom Field | Create, Get, Get Many, Update, Delete (leads, deals, contacts, companies, quotes, requisites) | | Custom Field Config | Create, Get, Get Many, Update, Delete, Get Field Types (any CRM type, smart processes included) | | Requisite, Bank Detail | Create, Get, Get Many, Update, Delete, Get Fields | | Address | Create, Get Many, Update, Delete, Get Fields | | Requisite Link | Get, Get Many, Set, Remove, Get Fields | | Requisite Template, Requisite Template Field | Create, Get, Get Many, Update, Delete, Get Fields (+ Get Available to Add) | | Document | Generate, Get, Get Many, Update, Delete, Set Public Link, Get Placeholders, Upload | | Document Template, Document Numerator | Create, Get, Get Many, Update, Delete | | Payment | Create, Get, Get Many, Update, Delete, Mark as Paid, Mark as Unpaid, Get Payment Link, and products and deliveries inside a payment | | Delivery | Get, Get Many | | Recurring Deal | Create, Get, Get Many, Update, Delete, Get Fields, Create Deal Now | | Order Link | Create, Delete, Get Many, Get Fields | | Call List | Create, Get, Get Many, Update, Get Entries, Get Statuses | | Stage History | Get Many | | Automation Trigger | Fire | | Sales Intelligence Trace | Create, Delete | | Currency | Create, Get, Get Many, Update, Delete, Get Fields, Get or Set Base Currency, Get, Set or Delete Localizations | | Digital Workplace | Create, Get, Get Many, Update, Delete, Get Fields | | Card Layout | Get, Set, Reset, Force Common for All | | Dictionary | eleven read-only lists: entity types, address types, CRM mode, custom field types and their settings |

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 (<pipeline> / <stage>). 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 Bitrix\Crm\Multifield\Collection 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 (CRM_FIELD_ERROR_VALUE_NOT_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 UPPER_CASE and come back in camelCase: RESPONSIBLE_ID 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>; 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.

| Resource | Operations | |---|---| | Message | Send, Update, Delete, Get Many, Search, Like, Mark as Read, Mark as Unread, Mark All as Read, Send Typing Indicator, Create Object From Message, Run Bot Command | | Chat | Create, Get, Find by Linked Object, Search, Update, Set Owner, Mute or Unmute, Leave | | Chat Member | Add, Remove, Get Many, Get IDs | | Recent Chat | Get Many, Get Changes, Pin or Unpin, Hide, Set Unread Mark | | File | Upload, Download, Attach Drive Files, Save to Drive, Delete, Get Chat Folder | | Notification | Send, Get Many, Search, Delete, Mark as Read, Mark All as Read, Answer, Press Button, Get Types | | User | Get, Get Many, Search, Get Colleagues, Get Status, Set Status, Set Away, Clear Away, Get Unread Counters | | Department | Get, Get Employees, Get Heads, Search | | Search History | Add, Remove, Get Many | | Event Queue | Subscribe, Unsubscribe, Get Many |

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/<user>/<webhook code>/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.

| Resource | Operations | |---|---| | Message | Send, Update, Delete, Mark as Read, Get, Get Context, Add Reaction, Remove Reaction | | Chat | Create, Get, Update, Leave, Set Owner, Add Managers, Remove Managers, Show Activity Indicator, Set Input Field | | Chat Member | Add, Remove, Get Many | | Command | Register, Update, Get Many, Unregister, Answer | | File | Upload, Download | | Bot | Register, Get, Get Many, Update, Unregister, Get API Revision | | Event | Get Many |

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=<bot id>]…[/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 BOT_TYPE_NOT_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 ROOT_OBJECT_ID. 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/<user>/<code>/download/ for Drive files, auth[ap]=<code> 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 DISK_OBJ_22000 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 USE_IN_FILTER. For files and folders these are ID, NAME, TYPE, CODE, STORAGE_ID, PARENT_ID, the dates and DELETED_TYPE; a filter on SIZE or CREATED_BY 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: {"<UPDATE_TIME": "2026-09-01 00:00:00"}.

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 DATE_FROM_TS_UTC and DATE_TO_TS_UTC, which are timestamps, and TZ_FROM 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 UF_USR_ in front: BADGE is stored as UF_USR_BADGE, 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 ERROR_METHOD_NOT_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', 'Bitrix\Crm\Integration\BizProc\Document\Quote', 'QUOTE_5'] | | Smart Process Item | ['crm', '…\Document\Dynamic', 'DYNAMIC_147_1'], with Container ID the process | | List Element, News Feed Process | ['lists', 'Bitrix\Lists\BizprocDocumentLists', '9'], with Container ID the list | | Drive File | ['disk', 'Bitrix\Disk\BizProcDocument', '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: PROPERTY_951, PROPERTY_1003. 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 PROPERTY_951.

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 CATALOG_CONTRACTOR_COMPANY (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 CAT_STORE_DOCUMENT_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 WRONG_AUTH_TYPE 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 work