Skip to content
Data between systems

System Integrations

Data moves between systems on its own, instead of being retyped. We connect your ERP, CRM, online shop, warehouse system, and spreadsheets so an order entered once reaches every place it is needed. Without replacing the tools your team already uses.
Book an intro call
Similar project Label Art's online shop integrated with the client's warehouse system

After the first call, you receive an initial assessment and a recommended next step.

The challenge

When is it worth integrating your systems?

The same data entered several times in different systems, orders retyped from email into the ERP, and three departments looking at three versions of the same number. An integration moves that data automatically and leaves one place where you can see whether it went through.

Technical details and delivery approach

System integration means connecting the tools a company already runs so data moves between them automatically. The ERP, the CRM, the online shop, the warehouse system, spreadsheets, and carrier systems were usually adopted at different times and never designed to work together. The result is work that consists of moving the same piece of information from one screen to another.

The cost of that shows up in three places. First, time: often hours a day spent retyping orders, invoices, and addresses. Second, errors, because with manual retyping a typo in a product code or a wrong quantity is only a matter of time, and it usually surfaces at the end of the process, at the customer’s end. Third, decisions made on different numbers, when sales, the warehouse, and accounting each report a different figure for the same product.

An integration does not require replacing systems. We start with a data flow analysis: where information is created, who retypes it, and what each system exposes. Then we agree the field mappings and the source of truth for conflicts, deliver the flow, and run it in parallel with the manual process until the results match. After go-live, monitoring stays in place, because vendors change their APIs and an integration has to respond to those changes.

Not every case needs an integration. If it comes down to one export per quarter, or the system vendor already ships a supported connector that covers the need, we will say so after the analysis. An integration pays off where the same data passes through people’s hands every day.

Case studies

For Label Art we connected the online shop to the client’s internal warehouse system, so stock levels update in real time and the gap between an order and actual availability disappears. For Promolist we built a process aggregating data from public registries into a single database of 5.4 million companies and 6.5 million addresses, plus an integration with Poczta Polska and courier companies that lets a dispatch be ordered without leaving the platform. Integrations are also a standing part of the custom systems we build - see the other case studies.

What we deliver
  • Data flow analysis: where information is created, who retypes it, and what that costs
  • Integrations with the ERP systems common in Polish companies - Comarch, enova, Subiekt, and others - plus CRMs, online shops, warehouse systems, and carrier systems
  • A connection through an API (the channel a system uses to share data with other software), file exchange, direct database access, or exports - we pick the method the system actually offers
  • Data mapping: product codes, units, VAT rates, and statuses agreed on both sides
  • Real-time or scheduled synchronisation, depending on how current the data has to be
  • Error handling: queues, retries, and an alert to a named person when something fails
  • A flow monitor showing what was sent, what is waiting, and what failed
  • Documentation of the mappings and knowledge transfer to your team
  • Maintenance after go-live: monitoring and a response when a vendor changes their API
Concrete scenarios

The integrations we build most often

Four areas come up most often: sales connected to the ERP, the shop connected to the warehouse, data from many sources merged into one database, and the company connected to its logistics operator.

Scenario 01

B2B portal integrated with the ERP

Orders placed by phone and email. A sales rep retypes the data into the ERP. The customer sees neither order status nor purchase history.

How it works
  1. We launch a self-service portal with a catalogue and per-customer pricing
  2. We pull stock levels, price lists, and order history from the ERP
  3. An order placed in the portal lands in the ERP with no sales rep involved
  4. Fulfilment statuses and invoices flow back to the customer automatically
  5. Mismatches go into an error queue instead of quietly disappearing
The sales rep stops being an order typist. The customer sees availability and status without calling the office.
Scenario 02

Online shop connected to the warehouse

The shop shows an item in stock, the warehouse does not have it. The gap shows up at picking, and the customer finds out through an apology email.

How it works
  1. We connect the shop to the warehouse system through its API
  2. Stock levels update in real time, in both directions
  3. Stock is reserved the moment the order is placed
  4. New products and variants are added in one place, not two
  5. Monitoring flags it when synchronisation stalls
No more orders for items that are not there. This is how the shop we built for Label Art works.
Scenario 03

Data from many sources in one database

Information about the same entities sits in several systems and registries. Each has its own format, some records are duplicated, some are out of date.

How it works
  1. We build a process that pulls data from every source on its own
  2. Duplicates are removed, bad records are caught, and formats are made consistent
  3. On top of the database we add search and filters matched to how the team actually looks for things
  4. Updates run on a schedule, with no manual import
One database instead of several lists. At Promolist that process covered 5.4 million companies and 6.5 million addresses.
Scenario 04

Integration with a logistics operator

Shipping addresses prepared in a spreadsheet, pasted into the carrier's panel, tracking numbers copied back into the system by hand.

How it works
  1. We connect your system to the operator's API - for Promolist that meant Poczta Polska and courier companies
  2. Addresses are validated before dispatch against official postcode data
  3. The shipping order is created from inside your own system
  4. Tracking numbers and statuses return automatically to the customer record
A dispatch ordered in minutes instead of hours spent assembling an address list.
Process

What does a system integration project look like?

Data flow analysis

We review the systems you run, what each of them exposes, and which data is retyped by hand today. It ends with a recommendation, an estimate, and a clear note on what cannot be connected without changes on the vendor's side.

3–10 business days

Mapping and integration design

We decide which field maps to which, what counts as the source of truth in a conflict, and how often data should sync. You get a document detailed enough to implement the integration, with or without us.

3–5 business days

Delivery and parallel testing

We run the integration on a copy of the data first, then in parallel with the manual process. Only once the results match do we switch the retyping off.

2–6 weeks

Monitoring and maintenance

We watch whether the flow is running, respond to errors within agreed SLA response times, and adjust the integration when one of the systems changes. The notice period is 30 days.

ongoing
Who it's for

This makes sense if...

  • 01 Orders arrive by email or phone and someone retypes them into the ERP.
  • 02 The shop, the warehouse, and accounting each show a different stock level for the same product.
  • 03 You have no in-house IT department and need a partner who owns the integration from analysis through maintenance.
A different approach may be better if...
  • — You need a single CSV export once a quarter - a manual file is cheaper than an integration.
  • — Your system vendor already offers a supported connector that covers the whole need.
  • — There is no agreement to grant API or database access on one of the systems - without it there is nothing to connect.
FAQ

Frequently asked questions about system integrations

Can our ERP (Comarch, enova, Subiekt) be integrated with e-commerce or a CRM?

In most cases yes. The ERP systems common in Polish companies - Comarch ERP Optima and XL, enova365, Subiekt - expose an API, file exchange, or database access, and each of those routes supports an integration. The difference is effort: with a well-documented API the work is faster, while file exchange means adding scheduling and handling for the times a file does not arrive. During analysis we check what your specific version and licence actually expose, because that varies between editions of the same system. If the integration turns out to require buying an extra module from your ERP vendor, we say so before the estimate, not mid-delivery.

What if a system has no API?

No API does not end the conversation. Other routes remain: scheduled file export and import (CSV, XML, EDI), reading directly from the database, integrating through a middleman the system already supports, or interface-level automation when nothing else is available. Each has a different maintenance cost and a different tolerance for vendor-side changes, so during analysis we show the trade-offs and recommend one. We are also straight about the limit: if a system is closed and the vendor will not grant access to the data, an integration makes no sense and it’s better to consider replacing the tool.

How long does a typical integration take?

It depends on scope, so these are typical ranges rather than a promise. Data flow analysis usually takes 3–10 business days, the mapping design another 3–5 days, and delivery itself 2–6 weeks, depending on how many systems are connected and how well documented they are. The largest share of that time goes to agreeing on the data rather than to code: which system is the source of truth, what happens to records with no counterpart on the other side, and how historical data is treated. We roll the integration out in stages - one direction of flow first, then the rest - so results appear before everything is finished. For a period the integration runs in parallel with the manual process so the outputs can be compared.

What happens when one of the systems changes after go-live?

That is expected: vendors update APIs, change field formats, and retire older versions. This is why the integration ships with monitoring that detects a stalled flow and sends the alert to a named person rather than a shared inbox. Under maintenance we adapt the integration to those changes and test it after every update. We also write the mappings and documentation so that a single changed field does not mean rewriting the whole thing. If you would rather maintain the integration yourselves, we hand over the documentation and the code - they are yours.

How do you secure the data flowing between systems?

Connections are encrypted, access runs on keys and technical accounts with the narrowest permissions the job requires rather than an admin account wired in everywhere. Sensitive data is stored only to the extent the integration needs it, with an agreed retention period. Flow logs show what was sent and when, without recording the full contents of personal data. We also agree where the integration physically runs, which matters under GDPR. A data processing agreement is part of the engagement whenever the integration touches personal data.

How much does an integration cost?

We quote after the analysis, because the cost depends above all on what the connected systems expose and how much data has to be reconciled. The estimate is broken down by stage - analysis, mapping, delivery, parallel testing, and maintenance - so you can see what you are paying for and where scope can be trimmed. Smaller, clearly defined integrations we can quote as a fixed price. On larger engagements we bill for hours actually worked, broken down by specific tasks. If the analysis shows that a vendor’s off-the-shelf connector covers the need more cheaply, we say so directly.

Does an integration mean replacing our systems?

No. The starting point is the opposite: we connect what the company already runs, because replacing an ERP or a warehouse system is a separate project with a completely different risk profile. An integration is usually cheaper and faster than a migration, and the team does not have to learn a new tool. It does happen that analysis reveals a system that cannot be sensibly connected and blocks the rest - we flag it and lay out the options, but the decision to replace it is yours.

Have a question that's not listed here? Write to us - we'll give you a straight answer.

Contact

Describe a problem or an idea for a product

Tell us which data you retype by hand today and between which systems. We will come back with whether it can be connected and what it takes.

In a few sentences: what you want to build or improve, why, and by when. No tech details needed - we'll ask about the rest.

Prefer to write directly? [email protected]

After first contact we schedule an intro call and agree on a plan of action.