System integration: ways to connect 1C, CRM and the warehouse, and the cost of ownership

System integration is a configured data exchange between applications in which an event in one system reaches all the other systems that need it on its own. In practice, the choice comes down to five patterns: scheduled file exports, direct point-to-point API connections, a message broker or data bus, off-the-shelf connectors and middleware platforms, and nightly ETL into a data warehouse for analytics. All five work; they differ in cost of ownership and in how they behave when something fails. Three numbers decide the choice: how many systems are in the loop, how many documents pass through it per day, and what a single duplicated or lost document costs.

Below, each pattern is examined separately: the volume it can handle and where it hits its ceiling. After that comes how exchange breaks in production, what the cost of ownership after handover consists of, and what the company prepares before the start. Why connect systems at all and which connection to start with, we covered in the article a zoo of services: how to connect 1C, CRM, the bank and Telegram into one loop (1C is the accounting and ERP platform most Russian companies run on): that one is about assembling a specific loop, this one is about choosing an exchange method and what it costs to run.

What methods of system integration are there?

There are five patterns, and their order in the list reflects growth in both reliability and cost. The more systems in the loop and the more expensive an error in a document, the sooner you have to move from files and direct connections to exchange with queues and a log.

Tools of this class are already widespread in Russian companies. According to a Nexign survey, 71% of organizations use integration tools: 62% run ETL systems, 44% data buses (ESB), 26% ELT, and 17% comprehensive platforms (summary on CNews, July 14, 2026). The publication does not disclose the sample size or survey period, so the figures show the balance of power rather than an exact market share.

The fifth row stands apart, even though it is the most widespread. ETL and replication solve a reporting problem: gathering data from 1C, from the CRM and from the warehouse into one place so that an owner’s dashboard can be calculated from it. The order–reservation–shipment–payment loop is not built on them: it needs freshness measured in minutes and writing data back into the systems. Companies often keep both layers at once, and confusing them is expensive at the start of a project.

A hybrid is the normal state of a mature loop. The standard website-to-CRM connection runs on a connector, the money-critical flow goes through a broker with an exchange log, and reporting is assembled by nightly ETL.

When is file exchange with scheduled exports enough?

File exchange holds up while there are two or three systems, the data is needed once a day, and a delay of a few hours breaks nothing. A nightly transfer of stock levels to an online store, an export of sales to accounting, sending a price list to dealers: these are the scenarios where a file is still cheaper than any other solution.

In Russian accounting, this is a standard method. The EnterpriseData format, which standard 1C applications use to exchange data with each other, works over four channels: web services, a file in a folder, FTP and email. The applications track sent and received messages, so each session transmits only the changes since the previous one (format description on v8.1c.ru).

The ceiling arrives at three points:

1. Delay. A sales manager sees the morning stock levels and sells what was already shipped overnight. The customer gets an apology instead of the goods.
2. Fragile format. A column is added to the export, and parsing on the receiving side fails. It is worse when the parser reads the data shifted by a column and silently writes nonsense.
3. Reruns. An operator restarts the exchange because “it didn’t go through,” and half the documents are duplicated. Without an identifier on every row, there is no way to tell a repeat from an original.

It makes sense to keep files as the main channel until staff start reconciling the results by hand. Once a daily “did everything arrive?” check appears, the exchange already costs more than it looks in the estimate.

When do you need a direct point-to-point API integration?

A direct API connection is the default method for two to four systems where data is needed within minutes. One system calls another using a strict format and gets an answer immediately: a website request lands in the CRM, a bank payment closes an invoice in accounting, an order status goes to the warehouse.

The Russian stack is ready for this. An automatic REST interface appeared in the 1C:Enterprise platform in version 8.3.5.1068. The application is published on a web server, and from then on an external system can read, change, create and delete objects via the OData protocol (post on the 1C:Zazerkalye blog, REST interface description on v8.1c.ru). CRMs, banks and marketplaces have APIs as well.

A direct connection breaks on three things:

1. An explosion of connections. Each new system needs a bridge to every existing one. Five systems may need up to ten such bridges, eight systems up to twenty-eight. Each one lives its own life and needs separate support.
2. Someone else’s API limits. Bitrix24, a Russian CRM and collaboration suite, throttles request rates with a Leaky Bucket algorithm. On most plans the counter drains at two requests per second with a bucket size of fifty requests; on the Enterprise plan it is five requests per second and a bucket of two hundred fifty. When the limit is exceeded, the next request gets status 503 and the code QUERY_LIMIT_EXCEEDED (Bitrix24 REST API limits).
3. No buffer. The receiver is down for fifteen minutes, and the data from those fifteen minutes goes nowhere. Exactly what was lost is known only to the log, which a direct connection usually does not have.

The limits deserve a closer look, because this is where delivery times are most often misjudged. Thirty thousand product items sent one at a time at two requests per second will take more than four hours of continuous work. A batch call helps only halfway: it holds up to fifty commands and consumes the request budget as one, but the nested calls are checked against a separate execution-time limit, returning 429 and OPERATION_TIME_LIMIT. The conclusion is simple: a large catalog is not pushed through REST in full. You send only the changes since the last session, or move that part of the exchange to the file channel.

Direct connections work well where there are few of them and they are simple. Once there are more than four, it is cheaper to build a central node once than to maintain a web.

Why do you need a message broker or a data bus?

A message broker turns a failure from an emergency into a delay. A message does not disappear until the receiver has acknowledged it, and it is redelivered once the receiver recovers. A bus adds routing: all systems connect to one node that knows where each document goes and keeps an exchange log.

The price of reliability is mandatory protection against repeats. The RabbitMQ documentation puts it plainly: acknowledgements provide “at least once” delivery, a message may arrive again, and the consumer must either deduplicate or process messages idempotently (reliability guide). In business terms, this means order number 4417 is created once, no matter how many copies of the message arrive.

A bus is justified with four or more systems, thousands of documents per day, and a high cost of a single error: where a duplicated shipment or a lost payment costs real money. Below that threshold it is overkill: design, queues and monitoring eat up more than they save.

The class is widespread in Russian companies: according to the same Nexign survey, 44% of organizations run an ESB. The most common use case for integration tools is transferring data between systems (63%), followed by reference data synchronization (44%) and end-to-end business processes (43%).

Should you go with an off-the-shelf connector or a middleware platform?

An off-the-shelf connector is worth taking when your scenario matches the standard one and you need the result this week. Website-to-CRM exchange, sending deals to a messenger, exporting marketplace orders to accounting: here the vendor’s template works, and building your own solution would be overpaying.

Three places where a connector hits its ceiling:

1. Process exceptions. Your own discount scheme, reservation for pre-orders, a separate procedure for branches and consignment goods. A template transfers the fields its author anticipated, and only in the direction they built in.
2. Data route. With middleware platforms, a copy of the data physically passes through the platform’s cloud, often a foreign one. For leads with names and phone numbers, this already falls under Federal Law 152-FZ, Russia’s personal data protection law, and the question of where the copy will end up is settled before connecting.
3. Subscription economics. The price is based on transaction volume and grows with the business. On a small exchange a subscription is cheaper than development; at thousands of documents the balance flips.

The sensible setup is mixed: standard flows stay on the connector, money-critical ones are built to fit. And the conversation is more useful when it is about flows rather than tools: which flow you are willing to hand over to someone else’s template and which you are not.

How does integration break in production?

Each pattern has its typical failure, and all four can be seen in advance if you ask the right questions about the exchange before work starts. Below is one failure per method, with the sign by which it is recognized in a working company.

1. Duplicates from redelivery. The disease of queues and reruns: a message went out twice, the receiver created two orders, the warehouse reserved the goods twice. The sign: someone cleans up duplicates by hand every morning. The cure is an operation identifier and a receiver that remembers what it has already processed.
2. Reference data drift. The disease of any exchange without a data owner: products and counterparties are created independently in two systems, and six months later “Romashka LLC” exists in three spellings while one product has two SKUs. It is no accident that reference data synchronization ranks second among use cases in the Nexign survey.
3. Silent failure. The disease of file exports and direct connections: the exchange stopped overnight, nobody saw the error, documents pile up, and reports look plausible. It is discovered a month later through a discrepancy in the money, and the whole period has to be untangled at once.
4. Dispute over the record owner. The disease of connectors with two-way sync: a price was changed in the CRM but is different in accounting; a delivery address was edited in two places. Until a master system is assigned for each data type, conflicts are resolved by hand case by case.

The scale of the problem is visible in global statistics too. The tenth annual MuleSoft report was prepared together with Vanson Bourne and Deloitte Digital: 1050 IT leaders were surveyed in October–November 2024. The average organization has 897 applications, of which 29% are integrated. 95% of respondents face difficulties connecting data across systems (report announcement, Salesforce, January 29, 2025). Connectivity is hard even where there are budgets and dedicated teams for it.

What makes up the cost of owning an integration?

The cost of ownership is four recurring expense items after handover, none of which appear in the development estimate. Comparing exchange methods by project price is pointless until these four lines have been calculated over a one-year horizon.

The return, meanwhile, is measurable. In the Nexign survey, about half of respondents name fewer routine operations, better data availability and reliable exchange among the effects of integration tools; the summary does not give exact shares for these three effects. Next come a lower total cost of ownership (31%) and faster time to market (25%). Someone else’s survey shows the direction, but you calculate your own economics from your own documents and hours.

What needs to be prepared before an integration starts?

Before the first line of code, the company settles six questions. None of them can be solved on the contractor’s side, and they are exactly what determines whether the project reaches its effect or stalls halfway.

1. A documented process. Where a document is created, who changes it, where its path ends. A process that lives only in people’s heads cannot be automated: the exchange will lock into code things nobody ever agreed on.
2. A master system for each data type. Accounting owns money, the CRM owns customers, the warehouse owns stock. Other systems read, but do not overwrite what belongs to someone else.
3. Access and permission separation. Separate accounts for the exchange, a defined set of objects exposed externally, read and write rights granted separately. Running the exchange with administrator rights is the most common security hole in this kind of project.
4. An owner for reference data. A real person who creates new items by the rules and resolves duplicates. Without them, shared identifiers drift apart within a single season.
5. A monitoring agreement. Who sees a failure, how quickly they respond, what they do with stuck documents. An unattended exchange works only until the first nighttime error.
6. A baseline measurement. How many documents per month are transferred by hand, how many minutes each one takes, what an hour of an employee’s time costs. Without these three numbers, there is nothing to show the CFO as the effect.

The first four items require no development budget and remove most of the risk. They also explain why the cost of an integration cannot be quoted over the phone: the price is built from the number of systems, the quality of the data and the number of exceptions in the process. If half of your accounting still lives in spreadsheets, start not with the exchange but with sorting out that area: we collected seven signs of that moment in the article when it’s time for a business to move off Excel.

What to choose: a boxed exchange or a system built around your process?

A ready-made exchange covers the standard movement of documents, and for standard flows it is enough. The fork lies in the exceptions: reference data, procedures, access rights and conflict-resolution rules are different in every company, and they are exactly what determines which document goes where and who is allowed to change it. A boxed connector transfers fields according to someone else’s logic. When your logic differs from it, people make up the difference by hand, and the savings disappear.

The second reason to look beyond the box is the time horizon. An exchange lives as long as the business process does: the product range changes, a warehouse is added, a new marketplace arrives. A method chosen for today’s volume must handle the volume two years from now, otherwise in two years the whole project is repeated. Which is cheaper in the end, a ready-made solution or a system built around your process, is calculated in the article your own system or a boxed product. Two related topics sit next to it: how to choose a CRM system, if the sales side of the loop is not settled yet, and WMS systems, if the warehouse is still tracked on paper.

An integration loop can also be built as custom development: with queues and duplicate protection, an exchange log, permission separation and failure monitoring, on your infrastructure or on servers in Russia. We work under a contract, the data stays within Russia, and ongoing support is discussed together with the project. The connections we have already built are shown on the “Integrations” page. Trying this on for your own loop? Tell us about your task: we will go through your document flows, name a suitable exchange method for each, and calculate the cost of ownership for the year ahead.

Sources

• CNews, July 14, 2026: Nexign survey on integration tools — 71% of organizations use integration tools, ETL at 62%, ESB at 44%, ELT at 26%, comprehensive platforms at 17%; use cases and effects of adoption. The publication does not disclose the sample size or survey period
• Salesforce, January 29, 2025: announcement of the tenth MuleSoft Connectivity Benchmark report — survey of 1050 IT leaders (Vanson Bourne and Deloitte Digital, October–November 2024), 897 applications per organization, 29% integrated, 95% face integration difficulties
• RabbitMQ, reliability guide — “at least once” delivery, message redelivery and the requirement for consumer idempotency
• Bitrix24, REST API limits — Leaky Bucket algorithm, two requests per second and a bucket of 50 on most plans, error 503 QUERY_LIMIT_EXCEEDED, up to 50 commands in a batch call, a separate execution-time limit
• 1C:Zazerkalye: automatic REST interface for applications — implemented in version 8.3.5.1068, OData protocol, publication on a web server and the set of available objects
• 1C: platform REST interface description — read, update, create and delete operations, user rights checks
• 1C: EnterpriseData exchange format — a business-oriented format, exchange channels (web services, file, FTP, email), message tracking and transfer of changes only