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.
Realistic ROI
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.
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.
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.
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.
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.
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.
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.
Related Reading
SaaS Integration Explained
The six patterns, what each costs and how to choose.
ERP to Ecommerce Integration
Connecting the back office to the online store.
WooCommerce Integration
The same job on a self hosted WordPress store.
Headless Commerce Integration
What decoupling the front end really costs you.
Product Data and PIM
Where product data should live before it reaches the store.
Custom API Integration
When the connector you need does not exist yet.
FAQ
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.
All discussions held in confidence. Australian-based consultants.