what we have connected.
We have connected Exact Online to Shopify, Shopware, Magento and CloudSuite. What gets exchanged includes orders, purchase orders, products, stock, prices, invoices and shipments. You can see examples in the Kisch case (CloudSuite) and the Verfwinkel case (Magento). We have also built many ERP integrations with Shopify.
the hard part: API limits.
Exact Online is strict about API limits, especially for larger customers. What matters is therefore how often you ask Exact Online for something. An integration that keeps requesting everything again works fine in testing with a handful of orders. With the real volumes it runs into the limit and stalls at the moment it is busiest, for example during a promotion or on Monday morning.
Suppose a webshop with a large catalogue fetches the whole catalogue every few minutes to update stock. Since the last run, only a small part has changed. The remaining requests return nothing new, but they still count towards the limit. If orders also have to be written, the budget is already gone.
how we deal with it.
- Smart searching with pagination. We request data in pages and make searches as precise as we can: not "all orders", but the orders that meet a condition.
- Only request what is not known yet. What we already have, we do not request again. Where a system allows fetching only the changes since a point in time, we use that and remember how far we got.
- A caching layer. Data that is needed often but rarely changes, we keep: which item in Exact Online belongs to a product code from the webshop, customer numbers, VAT codes, payment terms. Without a cache, every order line costs a separate request to look those up.
A cache is only useful if you know when it is no longer right. Each kind of data therefore gets its own expiry, depending on how often it changes. When the integration writes something itself, it updates its cache immediately. Data where a stale value costs money directly, such as the stock of items that sell out quickly, gets a short expiry or is fetched at the moment it matters.
A good integration also prevents double processing. A failed request is retried, and then the same order must not end up in Exact Online twice. So the integration first checks whether something already exists, and when it hits a limit it waits instead of dropping orders.
which system owns which data.
Record up front, for each kind of data, which system is in charge. Often that is Exact Online for prices and stock and the webshop for new orders, but every company has its own arrangements. Questions you answer together:
- Where is a price changed, and does the webshop have to show it within a minute, or is an hour fine?
- Which system counts the stock, even when you sell through several channels?
- Does a new webshop customer automatically become a customer in Exact Online, and what happens if the email address already exists?
Each answer sets a direction of traffic, and therefore the number of requests. Two systems that are both allowed to change the same data are a common cause of an integration that keeps repairing what it has just synchronised.
how you test.
Test with real volumes, not with ten orders. Count how many requests a full run costs, so you know how much room there is on a busy day. Test the awkward cases too: a request that fails halfway, the same order offered twice, a product that does not exist in Exact Online. And watch what the integration does when the limit is actually reached: does it wait and continue afterwards, or does it lose orders?
what to verify before go-live.
- A sample of orders in Exact Online checked for amounts, VAT, ledger account and linked customer.
- Counts in both systems compared side by side: orders, products and stock levels.
- For each kind of data, agreed how old it may be, and the cache expiry set to match.
- Recorded where errors land and who keeps an eye on them in the first weeks.
standard connector or bespoke.
Alumio offers ready-made connections from its library, a good starting point if you have little experience with integrations. In practice, most customers have quirks in the process that do not fit: an order that has to be split per warehouse, prices per customer group, different handling for foreign customers. That is why we build with generic components that we configure to your process.
what it costs.
We work with a fixed price agreed before we start. Before we name it, we validate the integration technically, so the risk for you is small. The price depends on the types of systems (well-known or legacy), the number of routes (how many data flows there are) and the complexity of the whole.
Is your combination not one of the webshops above? Read how we check that in has this been done before?. Tell us which webshop you use, how many orders, products and customers you have and how often they change, and we will tell you in one call what it involves.
