All nodes/Integrations/Bitrix24
Bitrix24 REST Call
Generic call to a Bitrix24 REST API method (crm.lead.add, crm.deal.list, ...) via an incoming webhook. Requires Bitrix24 Config via the 'bitrix24_config' port. method and params (JSON object) support Jinja templates.
Type in the graph: bitrix24_rest_call
Exec
An error branch can be enabled (expose_error_output) to handle failures on their own path.
Try it
Minimal working workflow
- Execute
- Data
- Execute + Data
Pick your own connection or knowledge base first — the graph carries REPLACE_ME.
When to use it
One node for the whole of Bitrix24: you name the method (crm.lead.add, crm.deal.list,
user.get) and its parameters, and the node builds the address from the webhook, sends the
request and unwraps the reply. There are no separate nodes for leads, deals and tasks, and none
are needed — the portal’s API is a pair of “method plus parameters”.
Assembling the same call with HTTP Request is a bad trade: the webhook address is a secret, and values pasted into the HTTP node are kept in the run log.
This is a graph step, not an agent tool. To let a model call a method itself, wrap the call in a WF Tool.
How it works
“Method” and “Params” are template fields. Parameters are written as a JSON object
({"fields": {"TITLE": "New lead"}}); an empty field means a call without parameters. When the
template substitutes a ready-made object as a whole — {{ nodes.build_params.output }}, say —
it is used directly, without re-parsing a string.
From the portal’s reply the node takes the contents of result and puts it in the output: in
templates, {{ nodes.<id>.output.result }}. A portal error (unknown method, revoked webhook,
insufficient rights) stops the node with the description from the reply; turn on “Error output”
to handle it inside the graph.
Common mistakes
- Parameters that are not an object. An array or a string is refused with “params must be a JSON object” — wrap the values in an object the way the method expects.
- JSON broken by substitution. A template value lands in the parameters verbatim, so quote strings yourself.
- Expecting paging data in the output. Only
resultleaves the node; the service fields Bitrix24 uses to report the rest of a selection do not. Pass the offset for the next page in the call parameters. - A mistyped method. The portal answers with a method error and the node stops — this is not an “empty result”.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Bitrix24 Configbitrix24_config | Datadata | — | required |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Successoutput | Execute + Dataexecute_data | object | |
Erroron_error | Execute + Dataexecute_data | — | shown when expose_error_output = true |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
Bitrix24 connectionconnection_id | string | "" | Saved workspace Bitrix24 connection, so a one-call graph does not need a separate Bitrix24 Config node. A node wired to the 'bitrix24_config' port wins over this field. connection: bitrix24overridden by port: bitrix24_config |
Methodmethod | string | "" | Bitrix24 REST method, e.g. crm.lead.add (Jinja templates supported) supports templates |
Paramsparams | string | {} | JSON object of method parameters, e.g. {"fields": {"TITLE": "New Lead"}} (Jinja templates supported) supports templates |
Shared fields
Every node has these three — the platform adds them, not the node author.
expose_error_output— When enabled, show an execution output to connect nodes that run if this step fails.