Bitrix Connector: Where the Exchange with 1C and CRM Breaks
The exchange between 1C, Bitrix, and CRM doesn't break "in general" — it breaks in four predictable places.
The first is stock desynchronization: an item is sold on a marketplace, but the write-off in 1C hasn't gone through yet, and the website keeps selling something that's no longer available.
The second is duplicate orders: a repeated upload after a timeout creates a second document for the same purchase, and the manager manually searches for which one is the real one.
The third is a stuck exchange queue. When a session with 1C breaks in the middle of a batch, the Bitrix connector either loses positions or accumulates them in a queue that grows faster than it's processed.
The fourth is lost statuses: payment went through, but the order sits as unpaid in CRM because the callback never arrived.
The cost of each failure is different, but it adds up to one thing: managers recheck data by hand, while the customer sees an unavailable item or waits for a confirmation that has already arrived.
The longer the desynchronization persists, the more expensive it is to sort out — discrepancies accumulate and require reconciliation over a period rather than a point fix.
Below we break down how this is closed at the connector level: idempotent order writing, checksums for stock, redelivery from the queue, and an event log that shows exactly where the exchange broke off.
What a correct Bitrix connector for business provides
A correctly built Bitrix connector is not a "bridge that simply passes data," but a layer with queues, idempotency, and retries.
It is what determines how fast orders, products, stock, and statuses are exchanged between the website, the accounting system, and marketplaces, and what happens when one of the services is unavailable.
When the exchange is built on direct synchronous calls, any hiccup on the side of the external system halts order intake: the customer places a purchase, but it never reaches the warehouse.
The first measurable effect is exchange speed. With batch processing and a reasonable batch size, catalog and stock data goes through in minutes rather than hours, and a new order appears in the accounting system almost immediately after it is placed.
This directly affects the share of lost orders: if the exchange runs with delivery confirmation and resending on failure, an order does not "hang" at the boundary between systems.
In practice, the share of lost orders drops to isolated cases, and stock discrepancies stop accumulating by the end of the day.
The second effect is predictable recovery time.
When the connector has an exchange log, idempotent keys, and automatic retry, a failure of an external service does not require manual investigation: unprocessed records return to the queue and arrive on their own, while the engineer can see at which step the exchange stalled. Recovery time after a failure is measured in minutes, not hours of manual reconciliation.
The third is the stability of the integration as an ongoing mode rather than a one-time setup. Exchange logs, discrepancy monitoring, and alerts about stuck records make it possible to notice degradation before it turns into lost orders. Let's break down how this is addressed at the level of the exchange architecture.
Integration methods: scheduled, event-driven, and via a data bus
Three exchange modes solve different problems, and the choice between them determines how fresh the data a manager sees in a record is and what happens when one of the sides fails.
Scheduled exchange is triggered by a timer and uploads in batches — predictable load, but the delay equals the interval.
Event-driven exchange is initiated by a change to an object: an order status in the CRM changes — the connector immediately sends it to Bitrix, and the data propagates within seconds.
A data bus places a buffer between systems that accepts events even when the receiver is unavailable, and delivers them after recovery.
| Option | When it fits | Limitations |
|---|---|---|
| Scheduled exchange | Reference data, stock levels, catalogs; systems without event APIs | Delay until the next run; when windows overlap, duplicates and record version conflicts are possible |
| Event-driven exchange | Orders, payments, statuses, requests — where freshness matters | Requires handling retries and event ordering; if the receiver is unavailable, events are lost without a buffer |
| Data bus | Multiple systems, high throughput, fault-tolerance requirements | Harder to maintain: queue monitoring and handling of "stuck" messages are needed |
In practice, the modes are combined: reference data is pulled on a schedule, while critical entities are handled via events.
Integration limitations more often lie not in the transport but in the data model: different counterparty reference lists, mismatched statuses, lack of idempotency on the receiver side.
That is why the connector includes an operations log, redelivery, and reference data mapping — so that a failure on one side does not turn into a divergence between databases.
How we implement a connector: from audit to handover
Implementing a connector is not "install a module and turn on the exchange," but a sequence with a verifiable result at every step.
Below is how our work is structured, so you understand exactly where quality is controlled and what happens before the exchange goes into the production environment.
- Integration audit. We analyze the current data flows: which entities already live in the CRM, which live in the accounting system, and where they are duplicated manually. We record the exchange directions (one-way or two-way), frequency, and volume of records. The output is a data map with a list of the fields that actually need to be synchronized, not all of them indiscriminately.
- Exchange schema design. We determine what is the source of truth for each field, how conflicts are resolved when changes occur simultaneously, and by what attribute records are matched between systems. Here we also choose the mode: scheduled exchange or event-driven.
- Connector setup. We build the mapping of entities and reference data, configure the permissions of the service account — only for the required sections, without excessive access. We enable logging right away so that incidents can be investigated based on facts, not guesses.
- Testing the exchange in a test environment. We run scenarios: create, update, delete, bulk export, resending the same record. We separately check the behavior when one of the systems is unavailable — the exchange must not lose data or spawn duplicates.
- Transition to the production environment. We launch on a limited data set, reconcile checksums and record counts before and after. Only after they match do we expand to the full volume.
- Handover to support. We provide documentation on the exchange schema, instructions for typical failures, and the procedure for handling data discrepancies. The team that will maintain the system knows where to look at the first error.
Each stage ends with a result that can be verified: a data map, a schema, a test run, a reconciliation. If a discrepancy surfaces at a step, it is resolved before moving on, not after launch.
What the customer receives after implementation
Work on the connector ends not with launching the exchange, but with handing over to the customer's team a package that allows the integration to be operated, extended, and transferred to another contractor without archaeology in the code. Below is what exactly remains in your hands.
- Connector configuration — working exchange profiles describing which entities are synchronized, in which direction, and at what frequency. The test and production environments are documented separately so that testing new rules does not affect production data.
- Data schema — a field mapping: how attributes of items, counterparties, and deals map to the receiver's objects, where the service communication identifiers are stored, and what happens when types mismatch. With it, a new developer introduces a new field in hours rather than weeks of analysis.
- Access policies — which accounts and roles read and write each entity, how permissions for bulk operations are restricted, and who receives a notification on failure. This closes the class of incidents where the exchange works but with excessive permissions.
- Exchange regulations — the schedule and launch conditions, the queue processing procedure, the rules of behavior when one of the parties is unavailable, the points of manual intervention, and the procedure for rolling back a failed export.
- Error handling and logging — which events are written, how to distinguish a one-off failure from a systemic one, where the notification arrives, and by what signs the on-duty operator understands that action is needed.
- Integration documentation — a description of exchange scenarios, instructions for typical operations, and a checklist for verification after changes in the accounting system or on the marketplace side.
- Development plan — a list of entities and platforms that the connector is ready to take on next, with an estimate of the effort for each connection.
We hand over the package within your environment: the repository, access credentials, and descriptions remain with you, not with us. Describe the task — we will come back with an estimate and a plan.
Case study: how a connector eliminated stock desynchronization on marketplaces
The client is a manufacturer of fast-moving consumer goods, selling through its own website on 1C-Bitrix and three marketplaces. Stock was managed in 1С, and uploads to the platforms were done manually: a manager reconciled tables once a day and edited product cards.
With an assortment of several thousand SKUs and dozens of orders per hour, the data diverged by midday.
What it was like before the integration
The share of SKUs with stock discrepancies between 1С and the platforms reached 18% on peak days. The exchange ran once a day, and the delay between a sale and a stock update was up to 20 hours.
Manual reconciliation and corrections took 3-4 hours a day, and marketplace sales had to be entered into the accounting system manually — hence duplicate orders and lost SKUs.
What was changed
We built a connector that keeps stock and orders within a single loop: 1С is the source of truth, and the platforms receive updates based on events rather than on a schedule.
A marketplace order automatically enters the accounting system, reserves the item, and returns the current stock to the platform. Conflicts over a single SKU are resolved by channel priority rather than by "who wrote last."
What it became after
The share of stock discrepancies dropped to 0.4% — these are mainly SKUs sold at the moment of exchange. The exchange time was reduced from 20 hours to 2-4 minutes.
Manual corrections of stock and orders were almost entirely eliminated: the manager spends 15-20 minutes a day on reconciliation instead of 3-4 hours.
The number of cancellations due to "out of stock" decreased severalfold — the platforms stopped selling what was not in the warehouse.
Such a connector is not a one-off customization but part of the accounting loop: when a new platform is added, the exchange logic is reused rather than written from scratch.
How does an event connector differ from scheduled exchange?
An event connector triggers at the moment data changes: a payment is made in 1C, a stock balance changes, a new counterparty appears — the platform immediately generates an event and passes it to Bitrix.
The exchange delay is measured in seconds, not minutes, and the customer sees the current order status in the CRM almost instantly.
Scheduled exchange works differently: an agent runs on a schedule, say once every 15 minutes, and uploads everything that has accumulated since the previous pass.
The difference in exchange delay determines where each approach is appropriate. For placing an order, reserving a product, or synchronizing payment status, every minute matters — here the event connector provides an accurate picture.
For exporting reference data, sales history, or a nightly stock reconciliation, a quarter-hour delay is not critical, and scheduled exchange handles it at lower development cost.
The load on the system is distributed differently. An event connector sends only changed records — that's dozens of operations instead of thousands, but it requires a queue and error handling: if Bitrix is unavailable, an event must not be lost.
Scheduled exchange is predictable in terms of load, but it runs a full or delta snapshot in its entirety, and on large catalogs this noticeably loads both systems at the moment it starts.
Support complexity also diverges. Scheduled exchange is easier to diagnose: there is an agent log, you can see what was uploaded and when, and a rollback comes down to re-running it.
An event connector requires idempotency — redelivery of the same event must not duplicate an order — and queue monitoring, otherwise a failure goes unnoticed until a client complains.
In practice, a hybrid is more often assembled: critical entities go by events, while large reference datasets go on a schedule. Such a Bitrix connector covers both speed and stability without overloading either 1C or the portal.
Technical concerns before starting integration
Before starting integration, the customer usually asks three questions: will the connector work on the current platform version, what happens if there is a data conflict between the two systems, and can changes be rolled back if something goes wrong. Below are the answers to them, without marketing.
Version compatibility: will the core need to be updated?
The connector is built for the current platform branch and tested on your configuration before work begins — the core version, module edition, and set of installed extensions. If an update is required, we say so immediately and show which modules it will affect.
There is no need to update the core "just in case": most often it is enough to isolate the connector from custom modifications via its own module so that a routine platform update does not break the integration.
Data conflicts: who wins when there is a discrepancy?
The conflict resolution rule is defined at the design stage: for each entity, a source of truth is determined — for example, orders are created in the CRM, while stock and prices come from the accounting system.
Synchronization runs via the change log with idempotent processing: re-delivery of an event does not create a duplicate, and any discrepancy is recorded in a separate table for review.
This way, the conflict is not "smeared" across the database but is visible at a single point.
Rolling back changes: what if the integration goes wrong?
Before deployment, a database snapshot is taken and a rollback point is fixed; changes go through a separate module — disabling it returns the system to its original state without modifying the core.
Bulk operations are performed in batches with logging, so an unsuccessful run is stopped and reviewed point by point rather than rewriting the data entirely.
Access and security: what do you request from us?
The connector operates through a separate service user with the minimum necessary rights — only those entities that participate in the exchange. Credentials are stored in a secure vault, not in the code, and all calls are logged: you can see who changed what and when.
If your question is not on the list — describe the task, and we will come back with an estimate and a work plan for your configuration.
Let's discuss your integration task
To come back with an estimate and a work plan rather than generalities, we need to understand your task at the data level: which systems are involved, which direction records flow, and what is considered the source of truth.
That's why we start the conversation not with a price list, but with a short breakdown — what already works, where it breaks, and what result is needed at the output.
Then we move along the engineering route: from scoping to handover to support. Each stage ends with an artifact that can be verified — this way the integration estimate relies on facts, not assumptions.
- We break down the task: which systems we connect, which entities and fields we transfer, who owns the data, and what happens when there's a discrepancy.
- We define the exchange scenarios: directions, frequency, volumes, and behavior when one of the parties is unavailable.
- We check access and constraints: API permissions, limits, test environments, and rollback capability.
- We design the Bitrix connector: entity mapping scheme, deduplication rules, error handling, and retries.
- We build and test on test data: we run typical and edge cases and compare the result against expectations.
- We roll out to the production environment with control: we log the exchange, set up failure alerts, and prepare a rollback instruction.
- We hand over to support: schema documentation, change management procedure, and a point of contact for questions.
After the breakdown, you receive a stage-by-stage estimate, a work plan with timelines, and the team composition. Describe your task — we'll come back with a plan and a proposal.