Bitrix24 Webhook Development: Setup, Processing, Integration

A deal moves to "Paid" status — within seconds, an invoice appears in the accounting system, a delivery request is created in the logistics platform, and an SMS goes to the client. Without webhooks, this would be manual work or a polling loop checking changes every minute. Webhooks are push notifications from Bitrix24 about events in the system. We, as developers with 5+ years of experience, ensure reliable implementation of such scenarios.

On average, a portal receives 50-100 events per minute at peak. Real-time processing of each is critical for business processes. Without a properly configured webhook system, companies face order delivery delays, duplicate invoices, and data loss. We solve this problem using proven architectural patterns and the Bitrix24 stack.

What Problems Do Webhooks Solve?

Webhooks automate reactions to events without human involvement. Main business tasks:

• Sync CRM deals with accounting systems (1C, ERP)
• Automatic order creation in logistics (CDEK, Russian Post)
• Sending notifications to clients (SMS, email, Telegram)
• Updating data in analytical dashboards

From practice: on one project, integration with 1C required processing 200 events per minute. We implemented async processing via RabbitMQ and achieved processing time under 1 second. That's 10 times faster than periodic polling, which had a 30-60 second delay.

Inbound vs Outbound Webhooks: What's the Difference?

Bitrix24 has two types of webhooks that are often confused:

Outbound webhooks are configured via the interface or REST API event.bind. Inbound webhooks are URLs with an embedded token that can be used to call Bitrix24 REST API without a full OAuth flow. The choice depends on the scenario: outbound for reacting to events, inbound for external management from third-party systems.

How to Set Up a Webhook Handler?

Step-by-step process for setting up a handler:

1. Register a subscription via event.bind specifying the event and handler URL.
2. Implement an endpoint that accepts POST requests from Bitrix24.
3. Verify the signature (check the authorization token and IP address).
4. Pass data to an async handler (via a queue).
5. Return HTTP 200 OK as quickly as possible.

Example subscription to deal stage change:

$client->call('event.bind', [ 'event' => 'ONCRMDEALSTAGEID', 'handler' => 'https://integration.mycompany.ru/b24/webhook/deal-stage', 'auth_type' => 1, 'options' => [ 'add_auth' => 'Y', ], ]); 

The full list of available CRM events includes over 150 names: ONCRMDEALCHANGE, ONCRMCONTACTCHANGE, ONCRMLEADCHANGE, and others. The complete list is available in the official REST API documentation.

Why Is Idempotence Important?

The webhook handler must respond quickly (up to 5 seconds) and process data asynchronously. If the response is slow or not 200 OK, Bitrix24 retries the request with exponential backoff. Without idempotence, repeated processing creates duplicates: e.g., double invoices or two delivery orders. Idempotence ensures that repeated calls do not cause side effects.

public function handleDealStage(Request $request): Response { if (!$this->verifySignature($request)) { return response('Unauthorized', 401); } DealStageChangedJob::dispatch($request->all())->onQueue('b24-events'); return response('OK', 200); } class DealStageChangedJob implements ShouldQueue { public function handle(): void { $dealId = $this->data['data']['FIELDS_AFTER']['ID']; $stageId = $this->data['data']['FIELDS_AFTER']['STAGE_ID']; // Idempotency check: already processed? if ($this->alreadyProcessed($dealId, $this->data['event_id'])) { return; } if ($stageId === 'WON') { $this->accountingService->createInvoice($dealId); $this->logisticsService->createShipment($dealId); $this->smsService->sendPaymentConfirmation($dealId); } } } 

How to Ensure System Reliability?

Signature Verification

Bitrix24 may pass an authorization token (auth[access_token]). The handler checks that the token belongs to the expected portal. For additional security, we add IP whitelisting — the list of Bitrix24 IPs is published in the official documentation.

Logging and Monitoring

All incoming webhooks are logged to a database table (e.g., vendor_b24_webhook_log):

• reception time
• event type
• request body (with token masking)
• processing status (pending / processed / failed)
• number of attempts

The monitoring dashboard shows: queue of unprocessed events, events with errors, average processing time. When more than 50 unprocessed events accumulate, an alert is sent via email or Telegram to the administrator.

Replay Pattern

If an external system fails (e.g., the accounting system is unavailable), some webhooks may not be processed. The module implements a replay: the administrator selects a date range and event type, and the system re-executes the handler for all events from the log.

What's Included in the Work

When ordering webhook development, you receive:

• Event map: analysis of business processes and mapping to Bitrix24 events
• Handler development (endpoint + async queue)
• Logging and monitoring setup
• Deployment and operations documentation
• Administrator training (1 hour)
• Technical support for 1 month after delivery

Timelines and Cost

Before development, we create an event map: which Bitrix24 event -> which action in the external system. This allows us to estimate the workload and identify potential conflicts.

Typical Mistakes in Webhook Development

• Missing idempotence → data duplication
• Synchronous processing → timeouts and retries
• Ignoring signature verification → vulnerability to fake requests
• Insufficient logging → hard to debug failures

Webhooks are an effective tool for integration, operating in real time without polling. They are comparable to the Webhook pattern.

Contact us for an estimate of your project — we will propose an optimal turnkey solution. 5+ years of experience and over 50 successful integrations guarantee quality. Order webhook development and get a ready solution in 2-3 weeks.