A year ago one of our e-commerce clients came to us with a problem I know all too well. The store handles a few hundred orders a day, and people in operations sit there retyping data by hand between three systems: the sales platform, the CRM and the ERP. A classic. At Web Systems, a software house from Łódź that has been running since 2006, we knew that patching this up would get us nowhere. It needed a proper API integration. The project covered connecting three independent systems carrying orders, stock levels, customer history, invoices and shipping statuses. We picked REST API, because no off-the-shelf plugin could handle this client’s non-standard business logic. A year has passed since the rollout. We collected plenty of conclusions and, honestly, some of them I wish I had known earlier.
Spis treści
Why we went for an API integration instead of ready-made plugins
Naturally, the first instinct is to look for something off the shelf. We tested three popular connectors linking the e-commerce platform with the client’s ERP. Each one failed in a different place. One could not handle the mapping of custom order fields. The second required manual work to synchronize returns. The third? It stopped working after an ERP update, because the plugin vendor had dropped support. So what now? Depending on an external plugin vendor with hundreds of transactions a day is simply a risk we could not afford.
The client needed full two-way synchronization. An order placed in the store lands in the ERP immediately. A stock level changes in the ERP, and the site updates at once. On top of that, the CRM collected contact history, complaints and buying preferences, and all of it fed into segmentation and personalized offers. No ready-made plugin could handle that three-way flow without compromises. I checked. Many times.
- Non-standard order statuses: the client used seven fulfillment stages of their own, which no connector recognized
- Dedicated B2B discounts: individual price lists for wholesale partners had to be synchronized from the ERP into the store
- Multi-warehouse synchronization: three locations with separate stock levels that had to appear as one consistent product range
- Automatic invoice generation: documents created in the ERP had to come back into the customer panel in the store
- Handling returns and corrections: a process requiring a simultaneous update in three systems
Tip 1: Before you start the integration at all, map the data flows between the systems. Draw a diagram: where each piece of data is created, where it goes, how often it changes. Without that map even the best API gives you nothing, because you do not know what you are actually synchronizing. I learned that the hard way.
Integration architecture: a middle layer instead of point-to-point connections
The most common mistake when connecting several systems? Building direct links between them. The store calls the CRM API, the CRM queries the ERP, the ERP updates the store, and you end up with a beautiful web of dependencies where one failing element takes down the rest. We went a different way. A dedicated middleware as the central communication hub. Every system talks only to that middle layer, never directly to the others.
This is classic separation of concerns, only at the infrastructure level. The store does its job: takes orders, displays products. The CRM handles customer relationships. The ERP controls the warehouse, finances and logistics. And the middleware? It transforms data, queues events and handles errors. A change to a data format in one system means a fix in the middle layer only. Not in every connected service. Trust me, that makes a huge difference in maintenance.
We considered two approaches to synchronization. Polling the systems at intervals, or an event-driven architecture where every change immediately produces a notification. In the end we built a hybrid. Orders and status changes go event-driven through webhooks, because speed matters there. Stock levels are polled every five minutes, because the client’s ERP did not support webhooks for warehouse operations. That was the compromise. And you know what? It has been running stably for a year.
Tip 2: Logging and monitoring from day zero. Record every API call, the response time, the data sent, the error codes. I tested this on my own skin: after three months without logs, debugging turns into reading tea leaves. You see the effect, but you have no idea when or why something went wrong.
The biggest technical problems in the first three months
The first serious headache? Differences in data formats. The ERP stored dates as DD.MM.YYYY, the store used ISO 8601, and the CRM used Unix timestamps. Product IDs were numeric in the ERP and alphanumeric in the store. Prices in the ERP included tax, while the store worked with net amounts. Every one of those differences is a separate transformation rule in the middleware. At the start it ate up far more time than we had assumed. But that is how it goes: these things only surface in practice.
The second problem showed up with higher traffic. Rate limiting on the ERP side. And that is where the fun began, because the system vendor did not document the API call limits. The technical specification said nothing about any restrictions. With a few dozen orders a day everything ran fine. But once traffic jumped to several hundred transactions, HTTP 429 errors started coming in. We had to introduce queuing with exponential backoff. Funny thing: we only found out about the limits from the error messages.
The third category is data conflicts. A customer changes their address in the store panel. At the same moment a consultant updates the same data in the CRM. And then what? Which record wins? Without a clear conflict resolution strategy, situations like that produced inconsistencies that the operations team only discovered at shipping time. Frustrating.
- Wrong mapping of units of measure: the ERP counted in pieces, the store in bulk packs
- Connection timeouts during large price list updates covering thousands of products
- Duplicate orders created when a failed API call was retried
- No idempotency on the ERP endpoints: sending the same request twice created two documents
- Product categories drifting out of sync between the store and the ERP after a manual edit in one of the systems
Security and authorization in communication between systems
Three systems mean three potential attack vectors. Customer personal data, financial information, order details and stock levels all travel through the API. A leak of any of it brings legal and reputational consequences. Seriously, this is no joke. And every system needed a different approach to authorization. The store offered OAuth 2.0, the ERP used static API keys, the CRM supported both models. Three mechanisms, zero standardization.
OAuth 2.0 wherever it was possible: automatic token refresh, granular permissions, all good. For the ERP with its static keys we built an extra proxy layer that limits the scope of access and logs every call. All communication runs over encrypted TLS connections, and we keep tokens and keys in a dedicated vault. Never in the source code. Never in the repository.
Tip 3: API keys in the code or in the Git repo? No. Just no. Environment variables and vaults such as HashiCorp Vault, even in small projects. One key leaked into a public repository can cost far more than an hour of configuration. I have seen this happen at other companies and, well, it was not pleasant.
We introduced key rotation every 90 days plus monitoring of unauthorized calls. The system alerts us when requests come from unknown IP addresses or when the number of authorization errors crosses a threshold. Twice these mechanisms let us detect attempted unauthorized access before it could do any damage. Because API integration security is not something you set up once and forget. It is a continuous process: reviews, updates, vigilance.
What changed after a year: the measurable effects of the integration
The biggest change people felt right away was the end of retyping data by hand. Before the integration, two people from the operations team spent around four hours a day in total copying information between systems. Four hours. Every day. After a year of automatic synchronization that time has dropped to a dozen or so minutes a day, mostly spent verifying exceptions and unusual cases. The team could finally take on the work that actually needs a human brain.
Order fulfillment time got shorter by 40 percent on average. Previously an order waited to be keyed into the ERP, then for a stock check, then for an invoice. Now? The whole flow runs automatically within a few seconds of the order being placed. The customer gets a confirmation with the invoice number almost immediately. The result? Better store ratings, more returning buyers. Simple.
According to Gartner analyses, an approach based on data and models is the foundation for building scalable business solutions. A properly defined architecture lets an organization scale its operations with minimal conflicts, makes onboarding new team members easier and improves the overall quality and resilience of the system.
And the maintenance costs? They turned out higher than planned, by around 30 percent. We had not anticipated how often the ERP would update its API and force changes in our middleware. Add to that the time spent on monitoring and responding to incidents. All in all the balance is still positive: the investment paid for itself in the eighth month, mainly through lower labor costs and the elimination of errors from manual data entry. We have no regrets.
FAQ: the most common questions about integrating a store with a CRM and an ERP
How long does it take to integrate a store with a CRM and an ERP through an API?
From our experience, a typical project integrating three systems takes 8 to 16 weeks, from requirements analysis to going live in production. It depends on the quality of the API documentation of the systems being connected, the complexity of the flows and the availability of test environments. And here is an interesting point: the longest part is usually not the programming itself, but agreeing on the business rules. What should happen when the data in two systems disagrees? Who wins? Discussions like that can drag on for weeks. I recommend reserving an extra two to four weeks for load testing and stabilization.
Does an API integration require changes to an existing online store?
Usually there is no need to touch the store itself. Most modern e-commerce platforms have a rich API that allows reading and writing data without digging into the source code. Changes may be needed if the store uses non-standard fields or processes that the API does not expose by default. In that case we build extensions on the store side, but the core of the platform stays untouched. That way later platform updates are not a problem.
What happens when one of the connected systems is temporarily unavailable?
The middle layer buffers events in a queue and retries delivering the data according to configurable rules. The ERP went down for a few minutes? Orders wait in the queue and go through automatically as soon as the connection is back. For longer outages the system sends alerts to the technical team. The priority is that no data can be lost. That is why the queuing mechanism writes events to disk, not only to working memory. We tested it by simulating outages lasting many hours and we did not lose a single event.
Summary: is it worth integrating a store with a CRM and an ERP through an API
After twelve months in production? Yes, definitely. But with your eyes open about the maintenance costs. The API integration brought real time savings, eliminated human error and sped up order handling. On the other hand, it required more ongoing maintenance work than we had assumed. Mainly because of API updates in the external systems and the growing scale of the data.
The most important lesson from this year is simple. An API integration is not a project with an end date. It is a living part of the infrastructure that needs monitoring, updates and constant adjustment. Treating it as a closed task? A straight road to a gradual decline in synchronization quality and to mounting technical debt. We found that out on our own skin.
If you are considering integrating your online store with a CRM, an ERP or other systems, we will gladly share our experience. At Web Systems we have been designing and delivering API integrations, business process automation and e-commerce solutions matched to real needs for years. Write to us, tell us about your project, and we will help you choose an architecture that works not only on the day of the rollout, but also a year and three years later.
