Skip to content

Latest commit

 

History

History
58 lines (38 loc) · 5.28 KB

File metadata and controls

58 lines (38 loc) · 5.28 KB

Overview of Events When Working with Requisites

{% note tip "" %}

If you are developing integrations for Bitrix24 using AI tools (Codex, Claude Code, Cursor), connect to the MCP server so that the assistant can utilize the official REST documentation.

{% endnote %}

Events allow applications to respond to changes in near real-time. Notifications are available for the addition, modification, and deletion of requisites, bank details, and custom fields of requisites, as well as for the registration and deletion of addresses. The methods for working with these objects are collected in the Details section.

Detailed information on working with events is described in the article Concept and Benefits of Event Processing.

Quick navigation: all events

How to Receive Events

You can subscribe to requisite events through:

An example of a handler code for an event is described in the article How to Test Your Handler for Processing Bitrix24 Events.

What the Handler Receives

Requisite events do not pass the entire object data — the handler receives only the key by which the object can be requested with a method.

Requisite and bank detail events. The data.FIELDS.ID field contains the object identifier. The rest of the data is returned by the crm.requisite.get and crm.requisite.bankdetail.get methods. Once the object is deleted, its data can no longer be retrieved by identifier.

Address events. An address has no identifier of its own, so data.FIELDS contains a composite key: the address type TYPE_ID, the parent object type ENTITY_TYPE_ID, and its identifier ENTITY_ID. The address can be found by this key with the crm.address.list method. The service fields ANCHOR_ID and ANCHOR_TYPE_ID are passed as well and contain the primary owner of the address: for a requisite address, it is a contact or a company; for a lead address, it is the lead itself.

Custom field events. data.FIELDS contains the field identifier ID, the symbolic object identifier ENTITY_ID, and the field code FIELD_NAME. The field description is returned by the crm.requisite.userfield.get method.

Server Availability for Sending and Receiving Events

{% include notitle Server Availability for Sending and Receiving Events %}

Overview of Events {#all-events}

Scope: crm

Who can subscribe: any user

#| || Event | Triggered || || onCrmRequisiteAdd | When a requisite is added manually or via the crm.requisite.add method || || onCrmRequisiteUpdate | When a requisite is modified manually or via the crm.requisite.update method || || onCrmRequisiteDelete | When a requisite is deleted manually or via the crm.requisite.delete method || || onCrmAddressRegister | When an address is registered manually or via the crm.address.add method || || onCrmAddressUnregister | When an address is deleted manually or via the crm.address.delete method || || onCrmBankDetailAdd | When a bank detail is added manually or via the crm.requisite.bankdetail.add method || || onCrmBankDetailUpdate | When a bank detail is modified manually or via the crm.requisite.bankdetail.update method || || onCrmBankDetailDelete | When a bank detail is deleted manually or via the crm.requisite.bankdetail.delete method || || onCrmRequisiteUserFieldAdd | When a custom field of a requisite is added manually or via the crm.requisite.userfield.add method || || onCrmRequisiteUserFieldUpdate | When a custom field of a requisite is modified manually or via the crm.requisite.userfield.update method || || onCrmRequisiteUserFieldDelete | When a custom field of a requisite is deleted manually or via the crm.requisite.userfield.delete method || || onCrmRequisiteUserFieldSetEnumValues | When the set of values for a custom field of list type is modified manually or via the crm.requisite.userfield.update method || |#