Integrating Bitrix24 with a website: where data diverges
Typical picture: a site on 1C-Bitrix takes orders and shows the storefront, while the Bitrix24 portal manages deals, invoices, and client cards.
As long as there is no integration between Bitrix24 and the website, each environment lives its own life, and the divergence between site and portal data begins with the very first transaction.
An order from the site is entered into the CRM manually, the invoice is issued a second time, payment is recorded separately — this is double order entry, which consumes the manager's time and breeds duplicate clients.
The gap between the site and CRM is not noticed immediately. A manager changes the price or delivery term in the deal, while the storefront keeps the previous amount: the client places an order at one price but receives an invoice at another.
The client card becomes fragmented — part of the history settles in order comments, part in portal messages, and a repeat request starts from scratch.
Stocks most often do not match. The warehouse writes off goods at the moment of shipment, the site — at the moment of order placement, and the portal — when the manager manually marked the reservation.
An item that is physically no longer available continues to be sold, and after order cancellation the reservation is not returned to the storefront.
The cost of error grows with volume: the more orders per day, the wider the divergence, the more expensive manual reconciliation, the higher the share of cancellations and returns, and the longer order assembly takes. Below we examine how this gap is closed by exchange between systems.
What a connected environment gives: unified data and less manual work
When the site and portal look at one database, the catalog is maintained once: the product card, properties, prices, and stocks are distributed across their sections without re-entry.
The exchange is built on an external key of the item — the position remains the same record and is not created anew in each session, so the unified product catalog does not spread into copies and does not require manual reconciliation.
Orders stop being duplicated. A request from the site reaches the portal once: the order key and repeated processing do not create a second document, so the class of errors "duplicate document" and duplicate client leaves the process.
The speed of request processing grows because the manager does not compare two databases by eye but works with a single order state.
Automatic stock updates go in batches by changes, not a full upload — the exchange completes faster, the queue does not grow, and the price and availability on the site match the accounting data.
The exchange log records every step, so a divergence is visible on a specific item and does not surface at the moment of shipment.
The result for manual operations: data entry shifts toward exception control — disputed items and divergences.
Our team configures such an environment on the bundle of Bitrix24, the website, and the accounting system, and we fix responsibility for the data composition and matching rules in the exchange regulation so that the result does not depend on a specific contractor.
Ways to connect the site and portal: exchange, bus, manual transfer
The integration mode between the site and Bitrix24 is chosen not by developer convenience but by two questions: how much the data can lag behind reality and what happens if one of the systems is unavailable. Below are the options that are actually chosen between on a project.
| Option | When it fits | Limitations |
|---|---|---|
| Exchange on a schedule | Reference data, prices, items; a delay of hours is acceptable | Data lags; edit conflicts are resolved by modification time |
| Event-driven exchange | Orders, payments, statuses — reaction needed within minutes | Depends on availability of both systems; queue and retries required |
| Intermediate database as a buffer | Systems operate at different rates and do not overlap in time | Another environment: maintenance, monitoring, cleanup |
| Manual transfer | One-time migrations, reconciliations, rare reference data | Does not scale, repeatability and traceability are low |
The bottleneck is usually not in the transmission channel but in the data model: different reference keys, duplicate counterparties, mismatched rounding and taxation rules.
Therefore, before choosing a mode, we agree on matching keys, conflict resolution rules, and which system owns the record.
In practice, the scheme is hybrid: reference data — on a schedule, documents and order statuses — event-driven, and the intermediate database covers windows when the portal or accounting system is unavailable. The delay is set separately for each type of data, not as one average figure.
Work order: from data analysis to handover to support
Integration with 1C almost never starts from a blank slate: prices, stocks, orders, and counterparties are already uploaded on the site and portal.
Before changing anything, we analyze which objects go in which direction, who owns the data, and where employees edit it manually — otherwise we would simply transfer the old errors into the new scheme.
- Integration audit. We create a map of connections: what is synchronized, on what schedule, in which direction, which edits bypass the exchange and why they appeared.
- Designing the data exchange scheme. For each flow, we fix the leading system, the set of attributes, the matching of items and counterparties, and the keys by which objects are linked between databases.
- Setting up synchronization. Exchange on a schedule and by event, service user rights, batch size, and queue order — catalog growth should not stretch the exchange into hours.
- Failure handling. Exchange log, redelivery, notifications to responsible persons, and rollback checkpoints: stopping one flow does not block the others.
- Acceptance checks on real operations. We run end-to-end scenarios — an order from the site, invoice, payment, return, new counterparty — and verify not the fact of a record but the match of data and reports in both systems.
- Handover to support. We provide documentation on the exchange scheme, the regulation for manual operations, access and monitoring, train employees, and fix the escalation procedure for divergences.
What remains in the project: exchange schemes, roles, regulations
Integration rests not on exchange code but on described rules: who owns the reference data, what to do in a conflict of product versions, which fields are considered the source of truth.
As long as these answers live only in the heads of developers, any modification begins with archaeology, and a change of contractor begins with restoring logic from exchange logs. Therefore, at acceptance we hand over a package of artifacts and check each one on a live scenario:
- Field mapping table — a table "field on the site ↔ object in Bitrix24 ↔ 1C attribute" with type, requiredness, and transformation rule: tax and unit of measurement are brought to the reference data rather than passed as a string.
- Data flow diagram — for each object: exchange direction (goods, prices, stocks, orders, statuses), frequency, volume, and the side whose record becomes primary.
- Access policies and roles — service accounts, their rights to sections and documents, the procedure for revoking access and changing keys.
- Regulation for divergences — how a conflict is recorded, whose version wins, who confirms a manual edit, and how it returns to the exchange.
- Integration documentation — exchange scenarios, module settings, task schedule, and dependencies between them.
- Recovery instructions — restarting the exchange for a period, re-uploading a stuck item, what to check when the queue stops.
- Monitoring log — which errors are logged and by what signs the on-duty operator understands that the exchange has degraded.
The package is self-sufficient: another team can reproduce the exchange from it without asking the author questions. A control scenario for each item at acceptance is needed so that the documentation remains working rather than formal.
Case: how stock divergences between the site and portal were eliminated
What it was before the rework
The store on the site side and the portal lived on nightly uploads: a catalog of 12,000 items was exchanged once a day, so stocks on the storefront lagged by almost a working day.
Operators manually reconciled divergences every morning across 3–4 product groups, each taking 40–50 minutes, and still by noon 8–12% of items diverged.
The cost of error was double sales and orders that had to be corrected after placement. The share of such orders reached 18%, and the buyer learned about a stock shortage an hour to an hour and a half after payment.
What was changed and what resulted
The exchange was moved to an event-driven scheme: a stock change in the accounting system immediately goes to the portal, and confirmation of receipt is recorded in the exchange log.
A queue with retry on failure and idempotent processing removed double write-off — a repeated message does not create a second order and does not deduct stock twice. The reservation is now placed at the moment of placement, so the storefront and portal show the same number.
Metrics after: stock divergence — 0.3% of items instead of 8–12%, planned reconciliations decreased from four to one selective per week.
Orders with manual correction — 1–2% instead of 18%, order confirmation time fell from 40–50 minutes to a couple of minutes, and the load on operators shifted from recalculating numbers to working with suppliers.
How exchange through an intermediate database differs from a direct connection
A direct connection between the site and portal means calling an external system at the moment of an operation: an order on the site immediately goes to the accounting environment.
The scheme gives minimal delay, but it has no buffer: if the environment is unavailable or the response comes with an error in the middle of a batch, the operation is lost or remains in an undefined state.
An intermediate database places a queue between the site and portal: both sides write to and read only it, and the external environment connects asynchronously.
A record is fixed with a status and timestamp, sending is confirmed by a separate step — if communication is unavailable, the accumulated data simply waits and goes out after recovery.
Exchange resilience rests on specific mechanisms: an idempotency key prevents an order from being duplicated when data is resent, retries with increasing delay do not overwhelm a failed service, and a separate queue stores records that could not be processed.
The price is a delay for the exchange cycle and an extra node in the scheme that must be maintained.
Diagnosing failures in the buffer scheme comes down to the log: you can see at which step a record got stuck, how many attempts there were, and what the receiving side responded.
In a direct connection, analysis goes through the logs of both systems and often runs into the absence of common record identification.
Therefore, the choice is not "what is more modern" but what is more critical: instant reaction on a simple flow or guaranteed delivery where a duplicate and a loss are more expensive than a waiting cycle.
Common technical doubts before starting
Doubts before starting usually concern not the idea of exchange itself but how it will behave on already populated databases, third-party code, and communication failures.
Below are questions asked on almost every Bitrix24 and 1C integration project, with short answers from engineers.
Our catalog and portal are already populated — will data be lost?
The exchange matches records by external identifier, not by name, so the first session is a reconciliation, not an overwrite. After that, only changes are transferred: existing items, prices, and counterparties remain in place, and duplicates are not created.
Third-party code runs on the site — will everything have to be rewritten?
Integration handlers connect to standard events and do not touch the storefront template or logic. We separately check areas where third-party code writes to the same entities: such points are separated by priorities, otherwise divergences appear.
What happens if communication between the site and portal is lost?
An unconfirmed batch remains in the queue and goes out again; the repeat is recognized by the external key, so duplicates do not appear in the databases.
When the channel is restored, the exchange catches up on the accumulated data, and the log shows what has already been applied and what is awaiting sending.
Will the exchange slow down managers' work in the portal?
If the exchange goes in batches and only by changes, and heavy reconciliations are moved outside the working day, the user does not notice a difference. Cards, deals, and reports open at normal speed.
Will portal updates break the integration?
The exchange is built on standard mechanisms and does not modify the core, so portal updates follow the usual procedure. Before moving to the production environment, we run the exchange on a copy — this catches incompatibility before users see it.
Let's discuss Bitrix24 integration: where we start
To come back with an estimate of the scope of work and an implementation plan, a full audit on the first call is not needed.
It is enough to discuss the integration task substantively: show the accounting system, the current exchange, and access, and our engineers will assemble the rest themselves. What is worth preparing for the conversation:
- The edition and degree of configuration modification: exchange with a standard and a heavily rewritten accounting system is designed differently.
- The list of objects that must travel between the site, portal, and accounting: items, prices, warehouses, stocks, orders, invoices, counterparties, deal statuses.
- The direction and frequency of exchange: only a catalog upload once a day or a two-way flow of orders and statuses with a delay of minutes.
- How the exchange works now — a scheduled job, file upload, web service — and what exactly stopped being satisfactory.
- Access for the audit: a test environment of the accounting system, a separate portal or administrative access to production with restrictions, access to the site server and exchange logs.
- Volumes: how many items in the catalog, how many orders per day, how many active portal users — the choice of synchronization mechanics depends on this.
- Who on your side makes decisions and confirms the rules for matching reference data, so that duplicates and divergences do not surface at the rollout stage.
Based on these inputs, we name the exchange mechanics, rollout procedure, and timelines. The next step is to describe the task in a convenient form, and we will come back with an estimate and work plan.