Skip to main content
Tech Titan

API Method Guide

event.bind

Module: System / eventsScope: Requires the scope of the entity being watched; app-level binding needs an OAuth app

Direct answer

event.bind subscribes a handler URL to a Bitrix24 event (e.g. ONCRMLEADADD, ONCRMDEALUPDATE). When the event fires, Bitrix24 POSTs a notification with the record ID to your handler — fetch details with a follow-up get call.

What event.bind does

The reactive layer: instead of polling for changes, your systems are notified when leads, deals, contacts, or items change. Combined with REST calls, it enables real-time sync, mirroring, and trigger pipelines.

Business use cases

  • Real-time sync to external systems when deals change stage
  • Data-quality watchers validating new records as they appear
  • Notification bridges (deal won → Slack/WhatsApp announcement)
  • Audit pipelines shipping change events to a warehouse

Typical fields and parameters

  • event — Event name: ONCRMLEADADD, ONCRMLEADUPDATE, ONCRMDEALADD, ONCRMDEALUPDATE, ONCRMCONTACTADD… (also ONCRMDYNAMICITEM* families for SPAs)
  • handler — Your HTTPS endpoint that receives the POST
  • auth_type / event_type — Binding options: online (immediate POST) vs offline (queued, pulled via event.offline.get) — offline suits high-reliability pipelines

Example workflow

  1. OAuth app (or webhook with event scope) calls event.bind for ONCRMDEALUPDATE → https://hooks.yourapp.com/b24/deal-update
  2. Deal 3120 changes stage; Bitrix24 POSTs { event, data[FIELDS][ID]=3120, auth[application_token] }
  3. Handler verifies the token, enqueues, responds 200 in milliseconds
  4. Worker fetches full deal via crm.deal.get, diffs against its store, syncs the change onward

Example request

POST .../event.bind.json

{
  "event": "ONCRMDEALUPDATE",
  "handler": "https://hooks.yourapp.com/b24/deal-update"
}

// What your handler later receives (form-encoded):
// event=ONCRMDEALUPDATE
// data[FIELDS][ID]=3120
// ts=1720340112
// auth[application_token]=abc123...
// auth[domain]=yourportal.bitrix24.com

Example response

{ "result": true, "time": { ... } }
// Verify active bindings any time with event.get.

Field mapping notes

  • Payloads carry IDs, not field data — the follow-up get is mandatory, so design for that extra call in your rate budget
  • Delivery is at-least-once and can be near-simultaneous for rapid changes — handlers must be idempotent and tolerate out-of-order events
  • ONCRMLEADUPDATE does not tell you which fields changed; keep a shadow copy and diff if you need deltas

Security notes

  • Always verify auth[application_token] against the value issued at binding time — an unauthenticated handler will happily process forged events
  • HTTPS only, unguessable handler paths, and reject payloads for portals you don't recognize (auth[domain])

Common errors

  • Handler never called — Binding user lacks scope, handler URL unreachable from the internet, or binding was silently dropped after repeated handler failures — re-check event.get and your endpoint's availability
  • Events lost during your downtime — Online events to a dead endpoint are retried only briefly. Use offline events (event.offline.get polling) or run a periodic reconciliation sweep with list-modified-since queries
  • Update storms from your own writes — Your sync writes trigger the events you're subscribed to — loop. Tag your writes (sync-timestamp field) and skip self-originated events

Production implementation tips

  • Respond 200 instantly and process from a queue — slow handlers get their bindings punished
  • Log every received event with ts and ID before processing; that log is your recovery source
  • Pair event-driven sync with a nightly reconciliation sweep — events are a fast path, not a guarantee

Webhook or OAuth app?

Webhook-bound events die with the creating user and have coarse control; OAuth app bindings are app-level and survive personnel changes — production event pipelines belong on apps.

Full decision guide: webhook vs OAuth app in Bitrix24.

When to use a queue worker

Non-negotiable here: the handler must be a thin authenticated enqueuer. All real work — the follow-up get, the diff, the downstream sync — happens in workers with retries.

How Tech Titan can help

Tech Titan builds production Bitrix24 integrations around event.bind and its siblings — with authentication, field mapping, queue workers, retry logic, duplicate handling, and structured logs as standard. If this method is on your critical path, bring the requirement to a free audit call and leave with an architecture sketch.

Book Free CRM Audit or DemoAPI Development service

Frequently asked questions

How do I process Bitrix24 webhook events?

Bind with event.bind, verify application_token on each POST, enqueue immediately, respond 200, then fetch full records and process from workers. Idempotency and a reconciliation sweep cover the delivery-guarantee gaps.

What is the difference between online and offline events?

Online events POST to your handler immediately; offline events queue inside Bitrix24 until you pull them with event.offline.get — better when your infrastructure's uptime can't be guaranteed.

Can I subscribe to SPA item changes?

Yes — the dynamic item event family covers SPA add/update/delete. Bind them like CRM events and route by entityTypeId in your handler.

Need event.bind working in production?

Bring your integration to a free audit call — you'll leave with an architecture sketch and an honest scope, whether or not you engage us.

Book Free CRM Audit or DemoContact us