Integrations for data exchange between IT systems

System integration is the structured exchange of data between CRM, ERP, 1C, warehouse, website, and marketplaces: it defines which system is the source for each entity, in what form it is transferred, how often it is sent, and what happens if a system fails. API integration is one way to enable that exchange: a connection to a specific system's programmatic interface. API answers the question of how to access the data, while system integration answers how the exchange is organized across the entire landscape. APIs alone do not provide controlled exchange: without a separate transfer layer, every new connection adds a dependency between systems.

There are four main types: point-to-point, a message broker, an ESB data bus, and iPaaS. They differ in where the ETL functions and storage sit relative to the systems: in point-to-point, both are inside the systems themselves; with a broker, queue storage is moved outside; with an ESB, both the ETL layer and the storage layer are separated. The choice depends on the number of systems and flows, fault-tolerance requirements, and who will maintain the exchange after launch. A comparison across four criteria is in the table above; the full breakdown is in the article. How to choose an integration type.

In point-to-point integration, systems exchange data directly and must know each other's format, speed, and availability. A broker externalizes message storage, but ETL logic remains on the system side, and the queue is delivered to the recipient as a whole, so the recipient has to filter it. ESB separates all three roles: the system generates and consumes data, the ETL layer passes it in the required form, and the storage layer stores it. As a result, the bus filters the stream for a specific consumer and controls the load on the source, while the failure of one system does not block the others. The comparison of the three types across five loose-coupling criteria is in the article Integrations for a Loosely Coupled Architecture.

The absence of an API does not block integration, but it changes the support cost. The selection order goes from the most reliable contract to the most fragile: an official API or webhook, then governed file exchange (CSV, XML, SFTP, email), then CLI or SDK, then a custom adapter, and only as a last resort browser automation for rare operations. The lower the level, the fewer guarantees the vendor provides and the more monitoring you need on your side. A breakdown of all levels with examples is in the article. Integration Without API: How to Connect a Closed System.

Cost is determined by the number of connected systems, the number of entities in the exchange, whether ready-made access and a server are available, and the transfer mode: batch exchange is cheaper than real-time. The project moves in stages - analysis of the current architecture, design of the target scheme, migration of the most urgent flows, then the rest - and most of the budget goes not into code, but into analysis and design before launch. You can estimate the amounts for your own landscape in integration flow cost calculator; we define the deliverable, timeline, and cost in documents before work begins.

Loss occurs when the source considers a message delivered but the recipient did not accept it, which is typical for direct point-to-point exchange. We design flows so that if the connection drops, the message remains unprocessed and is retried on the next pass, and the connector validates the system contract - data completeness and correctness - before sending it to the consumer. Key stages of each flow are logged: if an error requires action, a Telegram message is sent with a description and a link to details.