Bitrix24 implementation and customisation

The website, accounting system and CRM serve different purposes. The website accepts inquiries, Bitrix24 stores customer interaction history, and 1C manages documents and accounts. Integration connects these processes through agreed interfaces; it should not modify another system's database tables directly.

Each operation records the event ID, source, related entity and processing result. An API response confirms an individual operation, not necessarily completion of the entire business process: creating a deal may still need to be followed by creating a task.

Before development, we establish ownership of each field. If phone numbers are edited in CRM and payment totals are calculated in 1C, reverse synchronization must not overwrite them unconditionally. To prevent update loops, we track the source of changes and compare actual values before updating.

The form sends contact details, the inquiry, the originating page and traffic source. The server checks required fields again: browser validation improves usability but does not replace server validation. The inquiry ID is created once and retained during redelivery.

1. Accept and record

   We save the inquiry before contacting CRM. Receipt can be confirmed to the visitor while delivery to Bitrix24 is tracked separately.

2. Find the customer

   We normalize phone numbers and email addresses and look for related contacts. Multiple matches require an agreed resolution rule or manual review.

3. Create the sales record

   Depending on the CRM mode, we create a lead or a contact and deal. We specify the pipeline, owner, source and required portal fields.

4. Record the result

   We save the IDs of created objects. If the next step fails, processing resumes from the last confirmed operation.

{
  "entity_type": "CONTACT",
  "type": "EMAIL",
  "values": [
    "anna@example.test"
  ]
}

IDs and values in this example are illustrative.

Searching by phone or email helps identify the customer but does not itself prevent duplicate deals. That requires separate tracking of events and their related CRM objects. Contact merging needs its own policy, because automatic merging may affect sales history.

The accounting system is the source of payment information. CRM receives the result of an agreed accounting event, such as posting a payment document. The integration first uses the saved mapping to find the order and deal, then updates amounts and payment indicators.

A partial payment does not mean the order is fully paid or ready for delivery. Stage transitions depend on the contract: they may require full payment, a specified deposit or manual approval by a manager. This example covers one order in one currency, with no refunds.

After a successful update, save confirmation from CRM. If the deal mapping is missing, keep the event available for reprocessing after the mapping is repaired. Do not create a new deal merely because a payment could not be linked automatically.

An order enters delivery when the agreed conditions are met. For example, the contract is confirmed, the deposit has arrived, an assignee is selected and the specification is complete. Moving a deal to a stage may not be sufficient: some conditions are checked by the integration server or the portal itself.

1. Check readiness

   Check the stage, payment and required data. Return an incomplete order to its owner with a clear list of missing information.

2. Check for an earlier launch

   Look for a saved link between the deal and task. A repeated event must not create a second project.

3. Hand over to delivery

   Create a task or use the agreed project mechanism. Assign an owner and pass a link to the deal.

4. Return the status

   Save the task ID. Update return statuses under separate rules: completing one task does not always mean the order is complete.

{
  "fields": {
    "TITLE": "Start the project for deal #142",
    "RESPONSIBLE_ID": 7,
    "UF_CRM_TASK": [
      "D_142"
    ]
  }
}

IDs and values in this example are illustrative.

This example creates a task linked to a deal. On a real portal, use an existing user and account for required custom fields. Deadlines, observers, checklists and scope should follow the company's process rather than being identical for every order.

The data map defines more than field names. It explains who holds the source value, which changes are allowed and how to distinguish missing data from an intentional field reset. It is a core document for development and acceptance testing.

For updates, explicitly define how empty values are handled. An omitted field usually means "leave unchanged", while an explicitly empty value may mean "clear" if that is allowed. Verify this behavior for each API method used.

Retrieve the available fields and their characteristics for the relevant CRM entity type. Required fields can depend on portal settings and the stage. After configuration changes, review the data map and test it against sample scenarios.

The integration server makes requests to Bitrix24. The visitor's browser must not contain a secret webhook URL or OAuth token. Choose the connection method based on the number of portals, required events and access lifecycle.

{
  "entityTypeId": 2,
  "fields": {
    "title": "Website development",
    "opportunity": 250000,
    "currencyId": "RUB",
    "assignedById": 7
  }
}

IDs and values in this example are illustrative.

The crm.item.add method creates a CRM item; entityTypeId: 2 in this example represents a deal. This illustrates the parameter structure, not a universal ready-to-run request: a particular portal may require additional fields and permissions. Creating an item can also trigger configured automation, so review automation rules and workflows.

The handler stores the request result and the ID of the created entity. Analyze the method response for errors rather than relying only on the HTTP status. Before launch, check the required capabilities on the actual portal and keep test and production settings separate.

A queue separates event receipt from delivery to CRM. If an external service is temporarily unavailable, the accepted event remains in storage for later processing. Preserve the order of related changes where it affects the result, such as updates to the same order.

1. Accepted → pending

   The event is stored with its source, ID, timestamp and payload.

2. Processing → complete

   The worker checks mappings, calls the API and records the confirmed result.

3. Temporary error → retry

   Schedule another attempt with an increasing delay and a small amount of random jitter.

4. Needs review → resolved

   After retries are exhausted, or when data is invalid, the operation enters a separate operator review queue.

The hardest case is a response lost after a record was successfully created. The server does not know whether the deal exists, so blindly retrying can create a duplicate. Reconcile using saved mappings or an agreed external key before retrying. If the result cannot be established automatically, send the operation for review.

Define the number of attempts, maximum waiting time and alert conditions separately for each process. Account for REST API limits when setting queue throughput; check current documentation and portal conditions for exact values.

The log should explain what happened to a particular inquiry and what needs to happen next. Link all steps with a single operation ID and show the business context: order, deal, event type and current status.

Monitor the age of the oldest event, queue size and delivery time as well as error counts. Even without explicit errors, a growing queue can mean updates are arriving too late for the business.

Operators need a safe way to retry a specific operation after correcting its cause. Record the retry and its initiator in the history. Mask sensitive diagnostic data; make full payloads available only where justified by the task and access settings.

Grant only the permissions the integration needs. A full administrator account should not be the default. Check permissions to read CRM data, create the required entities, work with tasks and receive the events in use separately.

Store secrets in protected server configuration and exclude them from logs, repositories and client-side files. Authenticate incoming messages using the mechanism supported by the source; simply knowing the handler URL is not sufficient.

Before launch, define retention periods for events, logs and backups, what personal data is stored and who can access it. Test connection revocation separately: operations should stop in a controlled way rather than continue making endless unsuccessful requests.

Implementation delivers the agreed working integration and the materials needed to support it. Documentation must reflect the project's actual settings: a general architecture diagram cannot replace a technical description with a specific data map.

For every scenario, record the inputs and check the result in both systems and the log. Before enabling full-volume exchange, agree on how existing records are handled: initial migration and ongoing synchronization may require different rules.

The demo illustrates the process from inquiry to deal, from payment to a status change, and from a ready order to delivery. It uses sample data and does not confirm a connection to your portal or a particular 1C database.

To turn the example into a project, describe one real process, its data sources and the expected result. Then check system constraints, choose a connection method and agree on acceptance criteria. This makes it possible to assess the integration by its observable outcome, not merely by whether an API request is made.