Knowledge base
How an integration works
How data moves between your store and back office: matching, checks, approvals, queues and monitoring, with a worked example of one sync run.
Updated
Which data moves between your systems
Between a store and the systems behind it run five flows. Four of them move data: product data, stock, prices and orders. The fifth, PunchOut, is a session: your customer's buyer opens your store from their own procurement system and takes the cart back as a requisition.
Every flow starts with the same three questions. Which system does the value come from? When does it have to be in the other system? And which system wins when the two disagree?
| Flow | Direction | What moves | Usually owns it |
|---|---|---|---|
| 1. Product data | to the store | SKU, UPC or GTIN, title, attributes, images, variants | PIM or ERP |
| 2. Stock and availability | to the store | available quantity per location, lead time, expected date | WMS, ERP or supplier |
| 3. Pricing and customer terms | to the store | price level, contract price, quantity breaks, payment terms | ERP |
| 4. Orders, customers and shipping | from the store, status back | order lines, customer, ship-to address, payment status, tracking number | store for the order, ERP for the customer |
| 5. PunchOut | session in, cart back | login from the procurement system, cart lines in cXML or OCI | your customer's procurement system |
One owner per field
Under all five sits one rule: every value has exactly one system that decides it. That is set per field, not per system. Quantity comes from the WMS, price from the ERP and the product title from the PIM, even though all three systems have a field for quantity, price and title.
| Data | System of record | Direction | Sync behavior |
|---|---|---|---|
| Available quantity | WMS or ERP | to the store | on every change, per location |
| Price level and contract price | ERP | to the store | on change, plus a nightly full check |
| Title, description, images | PIM | to the store | on publish in the PIM |
| Order | store | to the ERP | on payment, once per order |
| Customer account and credit limit | ERP | to the store | on change |
| Tracking number | WMS or carrier | to the store | on shipment |
Without that rule, systems overwrite each other. An example: Akeneo publishes the title "Torque wrench, 1/2 in drive, 20 to 100 ft-lb" to Shopify at 02:00. The NetSuite item sync runs at 02:15 and writes the item's sales description, "TQ WRENCH 1/2DR", to the same field. Every morning the store shows the ERP's short text, and every afternoon someone fixes it by hand. With an owner per field, the NetSuite flow does not write the title at all.
How one sync run checks and updates your data
Every run is built first and written last. Take a supplier stock file going to a Shopify store: 4,160 rows, read at 06:05.
- Fetch. The file is read once its size has stopped changing, so a half-written export is never used.
- Check. 4,160 rows against 4,158 in the last run is within the limit for this feed. A file with 2,310 rows would stop here, before a single product changes.
- Match. 4,122 rows match a SKU. The 38 that do not go on the unmatched list with their supplier code.
- Diff. The matched rows are compared with what the store holds now. 640 quantities differ.
- Hold rules. None of the 640 changes trips a rule, such as a product going from 200 to 0 in one run.
- Write and log. Shopify takes up to 250 items per inventory call, so 640 changes are 3 calls: 250, 250 and 140. The diff is stored per product and per field.
Each write to Shopify carries the quantity it expects to replace, in the changeFromQuantity field. If a sale changed that quantity between the read and the write, Shopify rejects the line with CHANGE_FROM_QUANTITY_STALE and the integration reads the item again instead of overwriting the sale. Since API version 2026-04 every such call also carries an idempotency key, so a retried call is applied once.
The same stages apply to an order going to the ERP or a price list going to the store; only the source and the checks differ. How the stages work for supplier files is on supplier feeds.
How you review and approve changes
The integration writes at API speed. A wrong rule is wrong on 640 products within a minute, so the controls sit before the write, and they are yours:
| Control | What it does | Example |
|---|---|---|
| Dry run | runs everything except the write and shows the result | a new supplier feed runs a week without writing |
| Approval | holds a run until someone releases it | price changes wait for a person; stock goes straight through |
| Exclusion | leaves a product or customer alone | SKU 10482 keeps its promotional price until June 30 |
| Override | sets one value by hand that the integration does not touch | a ship date of 10 business days for a made-to-order item |
| Diff per run | lists every change per record and field | SKU 10482, available, from 14 to 8, run 18342 |
A run held by a rule waits with its reason attached: "312 of 4,160 products would go to 0, limit 5%". You look at the diff, and release it or leave it. The controls are described in full on dry run and approval.
Mapping, queues, access and monitoring
Moving data from A to B is the smallest part. What makes an integration reliable sits around it:
| Part | What it does | Example |
|---|---|---|
| Translation | converts values to what the other system expects | 19.95 becomes 1995 cents; a state name becomes TX |
| Direction and frequency | sets per flow what goes where, and when | stock on every change, journal entries once a night |
| Keys and permissions | keeps credentials out of the code and limits rights | read items, write sales orders, no administrator role |
| Queue | holds messages while a system is slow or down | an order waits 40 minutes during an ERP update, then lands once |
| Run overview | shows per run what was written and what was held | 1,240 rows processed, 3 rejected, with the reason per row |
| Alerts | warns when a run fails or the queue grows | a failed run, or orders waiting longer than expected |
Every retry of an order carries the same key, so a repeat does not create a second sales order. A message that still fails after the last retry goes to an error list with its original content and is processed again after the fix. The full sequence of an outage is in what happens when a sync fails.
You stay in control
A new integration runs dry first. A dry run processes real data without writing to the store or the ERP and shows what would change. After that you decide per flow whether changes wait for approval or go straight through. Products with a manual arrangement, such as a fixed promotional price, go on an exclusion list. A ship date you set yourself stays as an override. After every run there is a diff per record and per field: SKU 10482, available, from 14 to 8. See dry run and approval.
We build the integration for a fixed price, to your systems and your rules. Then we host it, run it and monitor it for a monthly fee, and change it when a source changes. You get a dashboard with logs and your own login.
Hosting and processing controls
Queued processing
Laravel queues with isolated workers. A 40,000-row feed does not block anything else, and a poison record does not take the run down with it.
Rate limits respected
Throttled, backing off on 429s, with retries that resume rather than restart. Shopify's leaky bucket and Magento's limits are designed around, not fought.
Separate databases and processing workers
Your own database, your own queue, your own workers. Another client's bad feed cannot reach your data or slow your processing down.
Idempotent writes
Re-running a feed does not double anything. Webhook races and duplicate deliveries are handled rather than hoped about.
Change limits
Every run is diffed before it writes. A feed that would zero 94% of your catalogue is held and reported instead of applied.
Full audit trail
Per product, per field, per run, with the source file recorded. Records where a price came from so a discrepancy can be investigated.
How changes to connected systems are handled
An integration that works today breaks when the systems around it change. Keeping up with those changes is part of running it.
| Change | Vendor's schedule | What we do |
|---|---|---|
| Shopify API version | a new version every three months, each supported for at least 12 months | move the integration to a supported version before the old one ends |
| NetSuite SOAP web services | no new SOAP integrations from 2027.1; all SOAP endpoints disabled in 2028.2 | build on REST with OAuth 2.0 |
| Business Central authentication | OAuth only since October 1, 2022 | service-to-service authentication, no stored passwords |
| A supplier changes its file | without notice | the run stops at the missing column; we change the mapping and process the held file |
When an existing integration or script is being replaced, the new one runs first next to the old one without writing, and the differences are logged before anything is switched. See replacing an integration. For the build, testing and ongoing support we handle for you, see how we help.
Frequently asked questions
Do we have to install or host anything?
No. The integration runs on our side. Your systems are reached through their own APIs, an SFTP folder or an email address, with credentials that have only the rights the integration needs. You get a login to the dashboard; nothing runs on your servers.
What does the monthly fee cover?
Hosting, monitoring and running the integration, and changing it when a source changes: a new API version, a renamed field, a supplier that rebuilds its export. The build is a fixed price agreed before the work starts. Tell us what you run and you get both.
Can we change the rules after go-live?
Yes. Exclusions, overrides and approval settings are yours to change in the dashboard. A change to a mapping or a rule, such as a new price level or a second warehouse, is made by us and runs as a dry run first, so you see what it would change before it writes.
Who sees what went wrong?
Both sides. We get the alert when a run fails or a queue grows, and the dashboard shows you the same run: which records were written, which were held, and the reason per record. A customer question about a wrong ship date can be traced to the run and the source file that set it.
What happens to orders while the ERP is down?
They wait in the queue. Each order is retried with growing pauses and carries the same key on every attempt, so a retry never creates a second sales order. Once the ERP answers again, the orders go in, in the order they arrived.
Do we need middleware between the store and the ERP?
Once more than two systems exchange data, yes. Four systems connected directly have six possible pairs, six systems fifteen. With one layer in the middle every system has one connection, the rules for each field sit in one place, and a failed message waits in a queue instead of disappearing between two systems.
What happens when a sync fails overnight?
The message stays in the queue and is retried with growing pauses. If the last retry fails, the message goes to an error list with its original content, and an alert goes out. In the morning you see which orders or SKUs are waiting and why, and they are processed again once the cause is fixed. Nothing is dropped without a record.
Which system should own inventory?
The system where units are counted when they are picked and received: the WMS when there is one, otherwise the ERP. The store never owns the quantity; it sells against it. Supplier stock can fill gaps next to your own count, set per field, as described on the stock and availability page.
Can you connect software that has no API?
Yes. Without an API there are three other routes: a database view or read-only replica, a scheduled export as CSV or XML over SFTP, and as a last resort a scripted browser session that reads a portal. Asking the vendor for an export or an endpoint is worth doing too; a concrete customer request often gets one.
Do we have to replace any of our systems?
No. The integration connects to the ERP, PIM, WMS and store platform you run today. What is settled up front is which system owns each field, for example quantity from the WMS and price from the ERP. That agreement changes nothing inside the systems themselves.
Does the integration keep working after a system update?
Vendors announce API changes in changelogs and version calendars; Shopify releases a new API version every three months. Following those changes and adjusting the integration is part of running it. When something changes without notice, such as a renamed column in an export, the run stops and reports the missing field instead of writing half a result.
Will my inventory be real time?
That is set per flow. Stock on the product page and an order that releases a shipment go on every change or within minutes. Price lists and journal entries go in a nightly batch. The ceiling is the source system's limit: at 300 requests a minute, 15,000 single-SKU requests take 50 minutes, so a full read every 15 minutes is not possible that way.
What is the difference between a standard connector, an iPaaS and a custom integration?
A standard connector moves a fixed set of fields in a fixed direction between two products. On an iPaaS you or a partner build the flows within what the platform offers. A custom integration is built on your fields and your rules, such as a price per customer instead of per price level, or an expected date from a supplier's file.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase