For Australian retailers and wholesalers on Magento 2 or Adobe Commerce

Magento and Adobe Commerce Integration Without the Six Hour Catalogue Update

Magento was built for businesses with complicated catalogues, several brands, multiple warehouses and both retail and wholesale customers in the same store. That capability is real, and it is also why an integration approach that works fine on a simpler platform tends to fall over here on about the third week.

This page is about the specifics: why the synchronous REST endpoints are the wrong tool for a large catalogue push, how multi source inventory changes what a stock update even means, why the website and store view hierarchy has to be settled before a single product is mapped, what the indexers and the cron queue are doing when the site goes quiet, and how to keep an integration working across a platform upgrade.

Book a Magento Integration Call (03) 9003 0111

Realistic ROI

3 API styles

Synchronous, asynchronous and bulk

Choosing the wrong one is the single most common Magento integration mistake

2 catalogue levels

Global attributes and per store values

Decided before mapping, or you rewrite the mapping later

Minutes to hours

For indexers to reflect a bulk change

Which is why a push that finished is not the same as a site that is updated

10 to 30%

Of build effort is usually attribute mapping

Rough guide for a real catalogue, and worth budgeting for honestly

Four Magento Realities That Decide the Integration Design

These are the four things that separate a Magento integration that scales from one that has to be rebuilt after the first big catalogue.

Bulk work belongs on the asynchronous queue, not the synchronous API

The straightforward REST endpoints process one record per request and wait for the answer. That is fine for a single order acknowledgement and disastrous for twenty thousand product updates, where it turns into hours of round trips, a web server tied up serving an integration instead of shoppers, and a timeout somewhere in the middle. The asynchronous and bulk endpoints accept batches, return immediately with a reference, and process through the message queue. Any integration that will ever push a full catalogue needs to be written against the queue from the start, because retrofitting it is close to a rewrite.

Multi source inventory changes what a stock number means

With multi source inventory a product does not have one quantity. It has a quantity at each source, grouped into stocks that are assigned to sales channels, with a salable quantity calculated from the sources minus reservations against open orders. An integration that writes a single number is fighting the model. The right design decides which sources the external system owns, writes per source, and reads salable quantity rather than raw quantity when it needs to know what a customer can actually buy. This also makes click and collect and ship from store possible rather than a fight.

Websites, stores and store views are a hierarchy, not a setting

Magento can run several brands or countries from one installation, each with its own catalogue subset, pricing, currency and content, arranged as websites containing stores containing store views. Product data can be set globally or overridden at store view level, and so can price. Until the integration knows which level owns each attribute, the mapping is guesswork, and the symptom is a price that is correct on one site and stale on another with no obvious cause.

Attribute sets are the real data model

Two products in the same catalogue can have entirely different attribute sets, and configurable products derive their variations from specific attributes that must exist, be the right input type, and be marked as usable for configurations. An ERP that exports a flat product list will not line up with this without deliberate transformation. Mapping attribute sets, option values and the parent to child relationship is unglamorous work and it is where most of the genuine build time on a Magento integration goes.

The Flows That Matter on a Magento Stack

Ordered roughly by how much manual work each removes for a typical Australian mid market retailer or wholesaler.

Queued batches

Catalogue publish from the source

Products, attributes, options, images, categories and the configurable to simple relationships are maintained upstream in an ERP or a product information system and published to Magento through the bulk endpoints in batches, with a record of which batch covered which records so a failure can be replayed precisely. The store keeps the fields it genuinely owns, usually merchandising position and marketing content, and everything else is read only in the admin so nobody edits a value that will be overwritten on the next run.

Source aware

Stock per source, salable to the channel

Warehouse and store quantities are written per source rather than as a single blended number, and reservations against open orders are left to Magento so the salable quantity stays honest. Safety buffers are set per source and per product line rather than globally, because a fast moving line and a slow special order line do not carry the same oversell risk. This is what makes it possible to sell store stock online without the counts drifting into fiction.

Invoice or summary

Orders into the back office

Orders flow into the ERP or accounting system as sales orders or invoices, with payment method, shipping, surcharges, discounts and tax each mapped to the right account and tax code. On Adobe Commerce with the business to business module, the flow also has to carry the company, the requisition or quote reference and the negotiated price, because a wholesale order that arrives without its company context is unusable to the finance team.

Status and consignment

Fulfilment, shipment and tracking

Picked orders come back as shipments against the correct source, with carrier and consignment number attached so the customer notification fires and the order status is meaningful. Partial shipments from different sources are normal on a multi source store and have to be modelled properly rather than collapsed into one, otherwise the customer gets one confusing email and the warehouse gets an argument.

One record

Customers, companies and price tiers

Customer records are matched rather than duplicated across the store, the ERP and the accounting system, with business to business companies and their users kept in the right structure. Customer group and tier price are owned by the ERP and read by the store, so a negotiated wholesale rate is maintained in one place. Matching rules combine email, normalised phone and, for trade accounts, the ABN, with anything ambiguous queued for a person.

Closed loop

Returns and credits

A credit memo raised in Magento becomes a credit note in the accounting system, restocking decisions are explicit rather than assumed, and stock returns to the correct source rather than to a default. Under Australian Consumer Law a faulty goods return is a different case to a change of mind return, and the two need different handling in both the finance record and the stock movement.

Magento Tasks Before and After Integration

Task	Traditional	Built for Magento	Notes
Full catalogue refresh	CSV import, hours, partial failures	Queued bulk batches	Batch size tuned to the environment. A replay covers a failed batch without redoing the whole run.
Stock across warehouse and shops	One blended number, oversells	Written per source	Salable quantity respects reservations, so open orders stop being double counted.
Orders into the ERP	Exported and keyed in daily	Created on payment	Tax, freight and surcharges mapped explicitly. Wholesale orders carry the company reference.
Wholesale price changes	Maintained in two places	Pushed from the ERP tier	Store view level overrides need to be deliberate, not accidental leftovers.
New brand or country site	Manual catalogue duplication	Scoped publish	The website and store view design does most of the work if it was set up properly.
Product images and assets	Uploaded by hand	Referenced and synced	Assets by URL rather than upload keeps bulk runs fast and the media directory sane.
Click and collect stock check	Phone the store	Source level availability	Only workable once stock is genuinely per source rather than a single pool.
A product that will not map	Skipped in the import log	Queued with the reason	Usually a missing attribute option or the wrong attribute set, and fixable in a minute if surfaced.

Where Magento Integrations Go Wrong

Everything was built on the synchronous API

It works beautifully in a demo with fifty products and becomes unusable at twenty thousand. The symptoms are a catalogue update that takes most of a night, a site that slows down while the sync runs, and a run that fails two thirds of the way through with no clean way to resume. Use the asynchronous and bulk endpoints for anything that touches more than a handful of records, keep the synchronous ones for single record events such as an order acknowledgement, and record the bulk reference so status can be checked and failures replayed.

Indexers and the cron queue were not considered

A successful write to Magento does not mean the storefront reflects it. Price, stock and category indexers have to run, and on a large catalogue they take real time. If cron is misconfigured, the queue consumers are not running, or indexers are set to update on save during a bulk load, you get either a site that never updates or a site that grinds. Set indexers to schedule for bulk work, confirm the consumers are running, and treat the queue depth as something monitoring watches.

The scope of each attribute was never decided

Attributes and prices can be global, per website or per store view. Once values have been written at the wrong level, cleaning them up means finding overrides that are invisible unless you look for them, and the classic symptom is a price that refuses to change on one store view no matter how many times the integration pushes it. Decide the scope for every mapped attribute up front, document it, and have the integration write at that level only.

Upgrades were treated as somebody else’s problem

Magento and Adobe Commerce upgrades change interfaces, and quarterly security patches arrive on their own schedule. An integration built against internal classes or a third party extension that has not kept pace will break on upgrade day. Build against the official REST interfaces, keep an inventory of every extension the integration depends on, test the upgrade on a staging copy with the integration attached, and agree who is responsible for the platform update before something needs patching urgently.

Credentials were issued as an admin user

Magento integration tokens carry the access of the role they are attached to, and an administrator token that leaks is a whole store. Create a dedicated integration with the narrowest resource access that works, keep tokens out of source control, rotate them, and restrict access by network where the platform and hosting allow it. Because these connections carry customer names, addresses and order history, the Privacy Act 1988 and the Australian Privacy Principles make least privilege a legal expectation and not just good practice.

Nobody load tested before November

An integration that is comfortable in July can be the thing that falls over in the last week of November, when order volume triples and the catalogue is being repriced daily at the same time. Rate limits, queue depth, indexer duration and database load all move together. Test at three times current peak on a staging environment sized like production, and agree in advance which flows can be throttled or paused during peak trading if something has to give.

How Yes AI Approaches a Magento Build

Environment and catalogue audit first

Version and edition, extension inventory, multi source configuration, website and store view structure, attribute sets, indexer mode, cron and queue health, and a count of the manual hours the current process costs. We put that in writing before quoting, because on Magento the environment decides the estimate.

Queue based by default, hosted by us

Bulk flows are written against the asynchronous endpoints with batching, cursors and replay from the start, and the integration runs on a managed cloud automation layer we operate rather than as an extension inside your store. Your Magento servers keep serving customers instead of hosting the sync.

Staging that matches production

Every change, and every platform or extension upgrade, is tested on a staging copy with real catalogue volume and the integration connected. Load testing at multiple times current peak is part of the build, not an optional extra we offer after something breaks in November.

Monitoring, bulk status and an exception queue

Bulk operation results are checked rather than assumed, queue depth and indexer lag are watched, failures alert a named person the same day, and products or orders that will not map go to a short review queue with the reason attached instead of vanishing into a log file.

From Manual Catalogue Work to a Connected Magento Stack

Five steps. On a typical mid market catalogue the first flow is live in four to eight weeks, and the audit tells us which flow that should be.

Audit the environment and the effort

Edition, version, extensions, source and stock configuration, store view hierarchy, attribute sets and indexer behaviour, alongside a timed list of what your team does by hand today. The output is a written picture of the platform and a costed list of the manual work.

Settle scope, ownership and the attribute map

Which system owns each attribute, at which scope, and which sources each external system may write to. This is the decision that makes the difference between a mapping that survives and one that gets rebuilt, so it is documented and signed off before build.

Specify each flow in plain English

Trigger, direction, batching approach, fields, matching rules, what happens to a record that will not map and who sees it. Written so a merchandiser and a financial controller can both check it, and approved by you before anything is built.

Build on the queue, test at volume, go live watched

Bulk endpoints with batching and replay, tested on a staging copy at production catalogue size and at several times current peak order volume, then a watched go live on the highest value flow with a rollback path ready.

Monitor, tune and extend

Queue depth, indexer lag and bulk status watched continuously, buffers and matching rules tuned against real traffic, upgrades rehearsed on staging before they reach production, and new flows added to the same layer as the business adds brands, sites or channels.

FAQ

Is there a difference between integrating Magento Open Source and Adobe Commerce?

The core interfaces are the same, so a well built integration works against both. The differences that matter are the extra capability in the commercial edition and what it adds to the integration surface. The business to business module introduces companies, company users, requisition lists, negotiable quotes and shared catalogues, all of which have to be mapped if you use them. The commercial edition also offers a managed cloud environment with its own deployment process and constraints. If you are on Open Source and considering the upgrade, the integration impact is worth costing as part of that decision rather than after it.

Why does our catalogue sync take all night?

Almost always because it is running through the synchronous REST endpoints, one product per request, with the integration waiting for each response. Twenty thousand products at even a quarter of a second each is well over an hour of pure waiting before you count retries, and it puts the load on the same web servers that serve shoppers. Moving to the asynchronous bulk endpoints, batching sensibly and checking the bulk status rather than each record typically turns that into a job measured in minutes. The second contributor is indexers set to update on save during a bulk load, which should be switched to update by schedule.

How does multi source inventory change our stock integration?

It means the integration should stop writing a single quantity and start writing per source. Each warehouse, store or third party location is a source, sources are grouped into stocks, and stocks are assigned to sales channels. Magento then calculates a salable quantity by subtracting reservations for open orders. If your external system writes one blended number it will fight those reservations and you will get oversells or phantom stock. The right pattern is to write the physical quantity per source and read salable quantity when you need to know what is genuinely available to sell, which is also what makes accurate click and collect possible.

Should the integration be built as a Magento extension?

Usually not. An extension lives inside the store, which means it shares the site’s resources, has to be maintained across every platform upgrade, and takes the site down with it when it misbehaves. Running the integration outside Magento against the official interfaces keeps the two lifecycles separate, lets the integration be monitored and replayed independently, and means a platform upgrade is a test rather than a rebuild. The exception is when you genuinely need to change behaviour inside the checkout or the admin, in which case a small purpose built extension alongside an external integration is reasonable.

Will an off the shelf connector do the job?

Sometimes, and we will say so. If you are on a single website with one warehouse, a modest catalogue, a common ERP and no wholesale complexity, a supported connector may cover it at a fraction of the cost of a build, and paying for a custom integration in that situation is a waste of your money. The point where connectors run out is fairly predictable: multi source inventory, several websites or store views with different pricing, business to business companies and negotiated prices, non standard attribute sets, or an ERP the connector does not support. The honest test is to list your ten most important field level requirements and check them against the connector before you sign anything.

How do we keep the integration working through Magento upgrades?

Three things do most of the work. Build against the official REST interfaces rather than internal classes, because those change far less often and changes are announced. Keep a written inventory of every extension the integration touches, since a lagging third party extension is a more common upgrade blocker than the platform itself. And rehearse every upgrade on a staging copy that has the integration connected and real data loaded, so the failure happens somewhere it does not cost you orders. Beyond that, monitoring that alerts a named person the same day means a surprise is a bad morning rather than a bad quarter.

What does a Magento integration cost and how long does it take?

A single defined flow such as orders into the ERP is commonly three to six weeks. A full stack covering catalogue publishing, multi source stock, orders, fulfilment, customers and returns is usually staged across three to five months, sequenced so the biggest manual burden lifts first. The main cost drivers on Magento specifically are catalogue complexity, how many websites and store views are in play, whether multi source inventory is in use, and how far your ERP export sits from Magento’s attribute model. We quote a fixed build price plus a flat monthly managed fee, and we would rather scope the attribute mapping honestly up front than discover it halfway through.

Make Magento Behave Like Part of the Business

Book a call. We audit the environment, the catalogue and the manual hours, then give you a written picture of what to connect first and whether a connector will do it for less. The audit is yours either way.