A webhook in Bitrix24 (Alaio) connects the portal to an external service without building an app: an inbound webhook gives the external system a URL key for calling the portal's REST API, while an outbound webhook makes Bitrix24 call your URL when an event fires. It is the fastest way to integrate — with limits the manual stays quiet about. This guide covers both types, their constraints, and the third scenario that comes up most: a webhook sent from a workflow.
What is the difference between inbound and outbound webhooks?
An inbound webhook is a URL with an embedded key that lets an external service call the portal's REST API methods: create a lead, update a deal, list tasks. Permissions are scoped when the key is created, and every action runs as the employee who owns the key. An outbound webhook is the reverse: you register your handler's URL and an event — lead created, deal updated — and Bitrix24 sends a POST there each time it fires. Combining the two gives a two-way integration: the outbound hook says "a contact appeared", the external service enriches the data and writes it back through the inbound one.
Where do I create a webhook and what should I check?
Both types are created in the developer resources section of the portal. For an inbound webhook, grant the minimum scopes: a leaked key with full CRM access hands your whole base to whoever finds it, so treat the URL as a password. For an outbound webhook, register the handler URL and use the application token Bitrix24 issues: the handler must verify that token on every request, otherwise anyone who learns the address can feed you fake events. Webhook availability depends on the plan, so check yours before designing an integration around them.
What are the limitations of webhooks?
Three, and integrations break on each. Request throttling: the REST API limits the request rate per portal, so bulk operations must be packed into batch calls instead of fired one by one. No redelivery: an outbound webhook is fire-and-forget — if your handler was down for a few seconds, the event is gone; Bitrix24 does not retry. Minimal payload: an outbound webhook carries little more than the entity ID and the event type, so you fetch the fields through the REST API anyway. A "reliable event bus on outbound webhooks" is therefore a myth: critical events need delivery with confirmation and retries.
How do I send a webhook from a workflow?
A common scenario missing from the stock actions: when a deal hits a stage, call an external system — accounting, a warehouse, a messenger bot (workflow basics are in the workflow guide). Two robots close it. HTTP request GET/POST sends a request with headers and a body — GET, POST, PUT, PATCH, DELETE or HEAD — and returns the response body, status code and a Y/N success flag into the workflow; the response is parsed with Extract value from JSON by path. Reliable webhook is for must-deliver notifications: it retries failed attempts on a configurable interval (up to ten attempts), lets you choose which status codes count as success, reports how many attempts were made, and can notify selected users if delivery ultimately fails. Need an answer right now — HTTP request; need guaranteed delivery — Reliable webhook. Both run on paid Bitrix24 plans.
Who can create webhooks, and can I restrict it?
Any employee who can open the developer resources section, not just administrators. The REST module reserves only some ready-made integration templates for administrators, such as those that add a widget to the CRM card. A plain inbound or outbound webhook can be created by an employee on their own, and it runs with that employee's permissions. There is no separate "webhooks for administrators only" switch. So an administrator should review the webhook list from time to time (the next section shows where it is). Blocking creation does not solve the main risk anyway: a webhook created by an employee sees exactly what that employee sees in the CRM.
Where can I see existing webhooks and delete one?
Open the developer resources section and go to the integrations list. An employee sees only their own webhooks; an administrator sees all of them and can filter by author. The key (the secret part of the URL) is shown only to its author: an administrator who opens someone else's webhook sees asterisks instead of the code. If an integration is running and nobody remembers who built it, look for it in this list by author and date, not by URL. You delete a webhook from the row menu in the list. After that, the external system immediately starts getting authorization errors, so find out who uses the key first. Check webhooks owned by former employees separately; what happens to them when someone leaves is covered in the employee offboarding guide.
Can I make a read-only webhook?
There is no "read-only" checkbox on an inbound webhook. Permissions are chosen per module when the webhook is created (CRM, tasks, users and so on), and within a module the webhook can both read and write. The only way to limit it is through the rights of the user it runs as: the webhook makes every request on behalf of its author and is bound by that author's role. That gives a working approach. Create a dedicated integration user, give them a CRM role with read-only access to the entities you need, and create the webhook under that user. If the key leaks, it cannot change or delete anything. Keep in mind that this user takes a seat in your plan's user limit. As a bonus, the integration stops depending on one particular manager: when that person leaves, the data exchange keeps working.
What should I give a contractor who will send us leads?
People usually ask for "a URL or a webhook", and both mean the same thing: the address of an inbound webhook their system will call with crm.lead.add. Issue a key with only the CRM module, created under the integration user from the previous section, not under your own administrator account. The address works like a password: anyone who has it can write to your CRM. If you stop working with the contractor, delete the webhook in the integrations list and access ends at once. If the contractor only needs to send requests from a website, a CRM form is simpler: then no REST API key is needed at all.
The outbound webhook robot: what goes in the Handler field?
Bitrix24 has a stock robot called "Outbound webhook". It has one field, Handler, where you enter your service's address: http or https, with a domain name. The robot sends a request there with the document identifier (document_id, for example deal DEAL_10) and moves on at once. It does not wait for a response and returns nothing to the workflow. It does not send the deal's fields either. Add the values you need to the address as parameters: https://example.com/hook?deal={=Document:ID}&sum={=Document:OPPORTUNITY}. One more quirk: if REST is not available on your plan, the robot silently does nothing, and no error shows up in the log. When you need an authorization header, a JSON body or the service's response in a workflow variable, use HTTP request GET/POST. When the event must not be lost, use Reliable webhook: it retries on a schedule, up to ten attempts.
My webhook is not working: what should I check?
Inbound returns an error: check the key's scopes (the method may need one it lacks), the key owner's status (a deactivated employee means a dead key) and the request throttle. Outbound never arrives: make sure the handler answers 200 quickly (a slow response counts as a failure), the URL is reachable from outside (not localhost, not firewalled) and the event is actually the one you think it is. And remember there are no retries: if the receiver was down, the event has to be recovered by hand — or sent through Reliable webhook from a workflow in the first place.
Where to go from here
Webhooks are the cheapest integration route in Bitrix24: inbound to drive the portal from outside, outbound for signals out, and — from workflows — robots with an HTTP request and guaranteed delivery, collected in the robot catalog. If your scenario is not covered, describe the task — we build the robot for free and add it to the shared library.