What an integration is and where it goes wrong

An integration is software that moves data back and forth between two systems, usually through an API: a fixed way for programs to talk to each other. When it works, you do not notice it. When it fails, you notice it in your revenue.

  • Prices drift apart: the shop shows a different price than the system the price comes from.
  • An order never arrives in the system that has to process it, and nobody sees it.
  • Error messages disappear quietly into a log file nobody reads.
  • Product data arrives in the wrong format and breaks pages.
  • An integration runs so heavily that visitors feel it.

Almost all of these problems can be prevented with checks and visible error messages. That is where I start, not with the integration itself.

How I build an integration

I start by reading: how the Magento shop is put together, which modules touch the same part, and what exactly the other system expects. Only then do I write code.

Every integration gets a check on what comes in. If a value is wrong, it does not enter the shop. Errors surface where someone will see them.

Changes go to a test environment first. The rollout happens without taking the shop down, and I do not run a full cache flush on production, because that throws away all stored pages and makes the shop slow for a while.

Integrations I worked on

These come from the Magento shop I work in myself. I leave out the names of the parties, the kinds of work are real.

  • A marketplace integration: products and orders flow between the shop and a marketplace.
  • A shipping integration with pickup points through a logistics partner: customers pick a pickup point at checkout, and the shipping details are passed on automatically.
  • Price synchronisation between two systems, with a check that stops wrong prices before they reach the shop.
  • An integration between Magento and a separate Next.js webshop, where orders land in Magento through the API. Stock and administration stay in one place.

Each of these has its own pitfall. With prices it is a wrong number, with shipping a missing address, with a second shop duplicate or lost orders.

Product data: repairing and rewriting

Not every integration goes to another company. Sometimes I connect your product data to Google or to an AI step that writes text.

  • Repairing product data for Google: in the shop I work in, 97 percent of the product JSON-LD was broken. JSON-LD is the structured data in a page from which Google reads price and stock. I fixed it.
  • An AI pipeline that rewrote over 2,000 product pages in three languages. A pipeline is a fixed series of steps that runs the same checks on every page.

Same rule here: read the existing data first, change it on a test environment, and only then on production.

From practice

A Magento 2 shop with integrations in every direction

This is the shop I work in myself: Magento 2.4.7 with over 3,400 products, about 13,600 product pages across four language versions and 328 active modules. The client stays anonymous, the numbers are real.

On a shop like this, a lot hangs together: a marketplace, a carrier, a pricing system and a second webshop. One error in an integration can show up on hundreds of pages.

over 3,400
Products in the shop
over 2,000
Product pages rewritten in three languages
97%
Broken product JSON-LD repaired

The shop reaches a mobile load time (LCP) of 2.14 seconds for real visitors, against 14 to 16 seconds before. Integrations should not make a shop slow or unreliable. With checks and a test environment, it ends up neither.

What I do not do

An integration runs day and night without anyone watching. So I stick to a few limits.

  • Pass data on without checking what comes in.
  • Try an integration out on production first.
  • Run a full cache flush on production.
  • Build an integration when a good one already exists that fits. Then I will recommend that one.
  • Bury errors in a log file nobody reads.

I also say so honestly when an integration costs more upkeep than it earns.

Scope and price

What an integration costs depends on the other system (does it have a good API?), how much data moves back and forth, and how many checks it needs.

I do not sell fixed packages for Magento work. After a first conversation I know what the integration has to do and we agree on the scope. More on how I price is on the pricing page.

Related pages