System Integration for Business: What to Do When It Breaks

System integration is a permanent connection between two or more programs, in which data moves between them automatically, by rules you set, without anyone retyping it. System integration for business rarely breaks on launch day — it breaks three months later, when a vendor changes its API, when the shop takes several hundred orders in an hour, or when the server on the other side stops answering. Proposals describe five implementation phases and a list of benefits. This piece is about what they leave out: what to settle before the work starts, and what happens when the other side goes quiet.

Where system integration for business actually starts

It starts with deciding which system is right when two of them show different data — not with choosing a tool. A source of truth is one named system whose value wins whenever there is a discrepancy; every other copy is only a reflection. Before anyone asks “Make or n8n”, someone has to answer “who owns the stock level”.

If you run a company in Poland, much of the stack you are connecting is already in place. On the back-office side sits an ERP — the software that holds accounting, inventory, and orders in one place — usually Comarch ERP Optima or XL, enova365, Symfonia, Subiekt GT and nexo, Streamsoft Prestiż, Sente, Microsoft Dynamics 365 Business Central, or SAP. On the selling side there is a platform such as Shoper, IdoSell, PrestaShop, WooCommerce, Magento, Shopify, Sky-Shop, Selly, or AtomStore, plus marketplaces: Allegro, Amazon, eBay, Kaufland, Empik. In the warehouse a WMS joins in — warehouse management software, which normally exchanges just two messages with the ERP: a picking instruction one way and a fulfilment confirmation back, over an API or a data bus.

Two-way synchronisation of the same entity is the most expensive and most failure-prone option you can pick, because it forces you to resolve conflicts in real time. Choose it only where the process genuinely requires it. Stock is where this bites first, because a company usually holds four different figures under that one word — picking the one that wins is covered in inventory synchronisation between the shop and the ERP.

The decision matrix to fill in before you choose a tool

For every entity, settle four things: direction, frequency, source of truth, and behaviour on conflict. Without that table the integration is guesswork, and mismatched records and overselling become a matter of time. Fill it in a spreadsheet before anyone writes a line of code — it is also the best attachment to a request for proposal and a natural part of a good software project brief.

The last row carries legal consequences of its own. Structured invoices and plugging your own software into KSeF, the Polish National e-Invoicing System, are a separate conversation, covered in KSeF integration for a custom system — Polish rules that apply to companies operating in Poland, not a general standard. This article is informational and is not legal advice.

Webhook or polling — the difference seen from the receiving end

A webhook is a notification that the sending system pushes by itself, at the moment of the event, to an address you have given it; polling is the reverse, where you periodically ask “is there anything new”. From the sales side a webhook looks better, because it works instantly. From the receiving side it is harder, and this is exactly where integrations in companies break most often.

The receiver of a webhook has to do four things that never show up in a proposal:

• Acknowledge before it processes anything. The sender has a time limit for a reply. If your system first writes the order into the ERP and only then answers, every ERP slowdown looks to the sender like an outage. The correct order is: store the raw message, reply, process separately.
• Keep a queue. A queue is a list of messages waiting to be handled, worked through one by one regardless of how fast they arrive. Without one, a sudden spike knocks the integration over and the events from the outage window are lost.
• Survive duplicates. The sender retries whenever it does not get an acknowledgement, so the same message can arrive twice. Idempotency saves you here: the property by which a message handled twice produces the same result as one handled once. In practice that means storing the event identifier and discarding repeats.
• Assume nothing about order. Events can arrive in a different order than they were created. A status of “shipped” must not fall back to “being picked” just because an older message turned up later. The timestamp or a record version number decides, not the moment of arrival.

Polling has one advantage almost nobody mentions: a missed event does not vanish, because the next run will see the changed record anyway. A lost webhook is gone for good. Mature integrations run both paths — a webhook for speed, and a scheduled re-sync once a day as a safety net.

What to do when a system has no API

Ask the vendor in writing before you conclude there is no API — sometimes there is one, but it is paid, unadvertised, or only available in a newer version. Some older accounting and warehouse systems on the Polish market genuinely have no public, supported interface, and then only worse options remain, worth knowing in order, best first. The full ladder — down to reading data off the screen — is walked through route by route in the guide on connecting a system without an API.

1. An official, supported API (REST, SOAP, or GraphQL, authenticated with OAuth 2.0, a token, or an API key). The only option the vendor is obliged to maintain.
2. Scheduled file export and import over SFTP. JSON, XML, or CSV dropped into a directory on a schedule. An old approach, but predictable and easy to audit. It needs a folder for rejected files and an alert when a file does not appear on time.
3. Integration through the system’s database. This works until the vendor changes the table structure in an update — and it will, because nothing was ever promised otherwise. It is technical debt with a deferred payment date: not covered by support, and capable of quietly writing data in a way the application does not expect.
4. Manual CSV import and export. Not an integration, a procedure. Acceptable as a solution for a few weeks, not for a few years.

The last sentence of that question is the important one. The answer decides whether the integration is a one-off cost or a standing one.

Point-to-point, a data bus, or iPaaS in a mid-sized company

Three arrangements are worth knowing, and each has its moment. A point-to-point connection, meaning a direct link between two systems, is the cheapest and quickest to launch — sensible when you have two or three systems and no plans for more. A data bus (ESB) is a central intermediary that all communication passes through; it starts to pay off once you have several systems and each new one would otherwise mean wiring connections to all the rest. iPaaS (Integration Platform as a Service) is an integration platform hosted by a cloud vendor who handles updates and availability while you build the flows inside it — convenient when you do not want to maintain your own infrastructure and accept the dependency on that vendor.

In Polish e-commerce, that middle layer is often filled by off-the-shelf integrators already on the market: BaseLinker, Apilo, Sellasist. EDI is a world of its own — standardised exchange of commercial documents, where the EDIFACT standard originated at the United Nations and was adopted by ISO as the ISO 9735 norm. The largest EDI users in Poland are retail chains, so if you sell into a chain, the buyer picks the standard and the format, not you.

When no-code stops being enough

Tools such as Make, n8n, Zapier, Microsoft Power Automate, Node-RED, and Pipedream make a good first version of an integration and a bad final one for a critical process. Six thresholds draw the line, not an opinion about any particular tool:

• Scale. Per-operation pricing stops being cheap exactly when the process becomes a daily one. Count the operations per month before you decide the cost is negligible.
• Data sensitivity. Personal and commercial data passes through the vendor’s infrastructure. Make runs in the cloud only; n8n is open source and can be self-hosted or run in n8n’s own cloud on servers in Germany. Check the location and the processing terms in the contract with the vendor, not in the feature list.
• Predictable latency. If a process has to finish within a set time, you need guarantees a shared plan usually does not offer.
• Auditability. “Why did this order not reach the ERP on 14 March” has to have an answer based on records, not on someone’s memory.
• Vendor lock-in. A scenario built by clicking does not move to another platform. The more logic it holds, the more expensive the exit.
• Scenario size. A flow with dozens of steps and conditional branches is already software — only without tests, versioning, or code review, and often with a single person who understands it.

Which thresholds you have already crossed is easier to judge against the side-by-side comparison of Make, n8n and a custom integration, including what self-hosting actually costs. Rewriting such a flow as your own service follows the same logic as mobile app development cost: you pay for edge cases and integrations, not for the number of screens. The same measure answers how long it takes to build an app. Assume from the outset that the first version covers one process — the same principle used when agreeing the scope of an MVP.

What every integration needs before you can live with it

An integration without monitoring is not finished, even when it works. The list below is the minimum worth requiring in the contract, whether an internal or an outside team does the work.

• Logs that include the message body. Not “write error”, but what came in, what was sent, and what the other system replied.
• Monitoring for silence. Alert on the absence of events, not only on errors — a shop that has sent no orders for four hours in the middle of a working day is a signal in itself.
• An alert that reaches a person. A specific person, a specific channel, a specific time threshold. A notification to an inbox nobody reads is the same as no alert.
• A queue for failed messages. A separate place where events rejected by the other side land, together with the reason for the rejection.
• A retry procedure. Someone non-technical has to be able to select the messages from the last two hours and send them again, without digging around in a database.
• An owner inside the company. One person who knows what synchronises with what and holds contacts at both vendors. Without that, the first outage turns into an argument about who should be calling whom.
• A plan for API changes. Write down where the vendor announces changes, who follows them, and how much time the team has to react. That is the question from the template above, moved into the contract.

This layer separates an integration from a one-off script, and it is the part most often missing from estimates — much like the ongoing performance work skipped on websites, where the result is measured with Core Web Vitals. If you are planning a wider project in which the integration sits alongside an app, take it down the same path as building a mobile app: scope and decisions first, tools second. If you want a second opinion on which connection is urgent and which can wait, describe your setup to us.