A webhook in Bitrix24 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.

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.