Why AliExpress integration breaks under order flow
AliExpress integration stops being reliable exactly at the moment when orders become numerous. In test mode everything looks smooth: a dozen SKUs, single purchases, responses arrive instantly.
Under flow the picture changes — order synchronization lags, some operations come back with an error, and managers manually reconcile what actually shipped to the buyer and what remained in the warehouse.
Inventory accounting is the first to fall apart. If catalog export and order intake run as independent streams without a single queue, a window appears between them: the item is sold on the marketplace, but on the website it is still available for purchase.
The stock discrepancy accumulates, and each such case means a canceled order, a refund, and damaged seller reputation. Manual data transfer masks the problem while the volume is small, but as it grows it turns into a constant operational burden.
A separate category of failures is stuck orders. The external service responds slowly or drops the connection, while the handler has no retries with a limit and idempotency.
The order is either lost or duplicated on retry, and sorting this out after the fact without an operations log is nearly impossible.
Peak load during sales finishes off whatever was held together by good faith: a spike in requests hits the external service's limits, and without buffering and a reasonable request rate the queue grows faster than it is processed.
Let's break down how this is closed architecturally — with queues, idempotent handlers, and inventory control at a single point of truth.
What direct integration with AliExpress provides and how to choose a mode
Direct integration with AliExpress is built on the official API: the store itself pulls product cards, prices, stock levels, and order statuses rather than waiting for a manual export.
The key decision here is not "whether to connect or not," but which synchronization mode to choose for your procurement and order processing workflow.
Synchronization modes and their effect
Full automation. A scheduler polls the catalog and orders on a schedule; price and stock changes are applied to the storefront without operator involvement.
Manual operations are reduced to handling exceptions — usually 2-5% of items: stock discrepancies, lots withdrawn from sale, disputed delivery statuses.
Hybrid scenario. Automation pulls the catalog and prices, but an order is sent to the supplier only after a manager confirms it.
This removes the risk of purchasing at an outdated price and keeps margin control — while the routine work of updating product cards is eliminated entirely.
Manual confirmation. Every order and every price change goes through an operator. Justified at launch or with a small volume, but as the catalog grows, processing time increases linearly, and discrepancies accumulate faster than they can be resolved.
| Option | When it fits | Limitations |
|---|---|---|
| Full automation | Stable catalog, predictable delivery times | Requires exception handling rules and alerts |
| Hybrid scenario | Products with volatile prices, margin control | Delay between order and dispatch to supplier |
| Manual confirmation | Small volume, test launch | Manual operations grow with the number of items |
What direct synchronization provides
Catalog update speed is measured in minutes, not business days: prices and stock levels on the storefront match the supplier.
Order automation eliminates double entry — an order from the store enters the procurement system without retyping, and delivery statuses are pulled back to the customer.
Idempotency is also addressed separately: a repeated poll does not create duplicate orders, and a failure on the supplier's side does not break the chain — the operation is retried via the log. This is the class of failures that in manual mode is noticed only when a customer complains.
AliExpress Open Platform provides data via REST with a rate limit on requests, so polling is built with quotas in mind and with caching of reference data — otherwise synchronization starts hitting limits rather than business logic.
How we implement the integration: from audit to handover
Integration with AliExpress is not "install a module and turn on the exchange." The main work goes into the audit: which entities already live in the catalog, how SKUs and variants are structured, where units of measurement diverge, who owns the stock when there are multiple warehouses.
At this stage we record the discrepancies between the accounting system and the marketplace, because it is precisely these that later produce duplicate product cards, lost orders, and negative stock.
Next, we design the data exchange scheme: which events go from the marketplace to us, which go back, at what frequency, and what to do when one of the parties is unavailable.
Separately, we describe the rules for matching products and resolving conflicts when price or stock changed on both sides simultaneously.
- Integration audit. We analyze the current processes, catalog, warehouses, and order statuses. The output is a discrepancy map and a list of entities that need to be linked.
- Exchange scheme design. We determine the directions of flows, polling frequency, message format, and product matching rules. We define the behavior during failures and retries.
- Synchronization setup. We bring up the exchange of stock, prices, and orders, configure queues and retries so that a connection break does not lose data.
- Testing on real data. We run scenarios on a live catalog and real orders: bulk update, cancellation, return, partial shipment. We look at where stock diverges.
- Failure handling. We check the behavior when the marketplace is unavailable, events are duplicated, and manual edits are made in the panel — the system must converge to a correct state.
- Documentation handover. We provide the scheme description, maintenance regulations, and instructions for employees, and conduct training for the customer's team.
- Post-launch support. For the first while, we monitor discrepancies and adjust the matching rules based on actual data.
Each stage ends with an artifact: a discrepancy map, a flow diagram, a configured exchange, a verification report. This way, at handover the customer's team is left not with a "black box" but with a clear regulation.
How does full synchronization differ from selective synchronization?
Full synchronization uploads the entire catalog and order history in full: on the first connection, the AliExpress integration runs through all products, prices, stock, and statuses, and then keeps the mirror up to date.
Selective synchronization works on a subset — specific categories, suppliers, warehouses, or only those items already selling on your storefront. The difference is not "better/worse," but rather how much data you are willing to keep in the loop and how often to update it.
Full mode provides predictability: stock on the site always matches the source, order status is pulled in without manual reconciliation, and discrepancies are caught at the exchange stage rather than at the customer complaint stage.
The price of such predictability is the load on the exchange and the time of the first upload: while the catalog is large, the initial pass takes hours, and until it completes, some items live with incomplete data.
Therefore, full synchronization is usually put on a schedule with windows outside peak load, rather than triggered on every change.
Selective synchronization solves the opposite problem — limiting the flow. If you sell 200 items out of 20,000, running the entire catalog is pointless: selective mode updates only the needed groups, delivers changes faster, and puts less load on both sides.
The limitation here is different: everything that did not make it into the selection lives its own life, and you will not see a discrepancy on it until you expand the filter. This is a conscious trade-off, not a defect.
The choice of mode comes down to order flow and catalog structure. With a steady flow and a small assortment, full synchronization is easier to maintain: fewer rules, fewer places where something can break.
With a broad catalog and a narrow storefront, selective synchronization saves exchange resources but requires discipline — filters must be reviewed with every expansion of the assortment, otherwise new items will not be picked up.
In practice, the modes are combined: catalog and stock are pulled selectively by active groups, while orders and statuses are pulled in a full stream, because a lost order costs more than an extra request.
The limitations of synchronization are the same in both cases: the exchange frequency is capped by the external side's limits, and edit conflicts are resolved by a priority rule — whose price is considered the truth when there is a discrepancy.
Describe your assortment and order flow — we will come back with an assessment and a plan for which mode covers the task without unnecessary load.
Case Study: How We Eliminated Manual Order Transfer
Before implementation, managers manually transferred orders from the AliExpress panel to the accounting system: they copied the SKU, quantity, delivery address, and payment status.
At a volume of 300-400 orders per day, this resulted in up to 4% discrepancies — some items went to shipment without confirmed payment, and some were lost when the status changed on the supplier's side.
Resolving each discrepancy took 15-20 minutes, and the peak load fell at night when the on-duty shift is minimal.
What We Changed
We built a synchronization layer on the side of our application: a subscription to AliExpress webhooks for order events and a separate status poll every 10 minutes as a safeguard against missed notifications.
Each event was assigned an idempotent key so that repeated delivery wouldn't create a duplicate order. The field mapping was moved into a separate configuration — when the response structure changes, only one mapping table is edited rather than the handler code.
What Changed After
The share of manual operations dropped to zero on typical orders, and the processing time for a single order was reduced from 15-20 minutes to a few seconds.
Payment and status discrepancies stopped reaching the warehouse: the system reconciles the order state with the accounting system and raises a flag if the data diverges by more than one synchronization cycle.
The on-duty shift stopped being a bottleneck — nighttime peaks are processed by the same pipeline as daytime ones.
| Metric | Before | After |
|---|---|---|
| Order processing time | 15-20 minutes manually | seconds, without manager involvement |
| Discrepancy rate | up to 4% of orders | isolated cases, all flagged |
| Nighttime load | requires an on-duty shift | processed automatically |
The synchronization logic was built on AliExpress Open Platform — the platform's official interface, which eliminates the risk of being blocked for non-standard methods of accessing data.
What if the supplier changes the response format? The field mapping is moved into configuration, so the edit takes minutes and doesn't require rebuilding the processing logic.
Can we roll back to manual mode? Yes, the synchronization layer is disabled with a flag, and orders continue to arrive in the panel — this is a safeguard during scheduled maintenance.
Compatibility, migration, and rollback: what to discuss before the start
Integration with AliExpress rarely lives in a vacuum: it fits into an existing store, inventory accounting, and logistics.
That is why, before the start, we lock down three things — how the new synchronization will coexist with the current stack, how the data transfer will proceed without downtime, and what will happen if the external service starts responding with errors.
We verify integration compatibility at the level of exchange formats, product catalogs, and order statuses, not "by eye."
What if we have a non-standard platform? Then we agree on exchange through an intermediary layer: it brings the data to a common form, and the store's core remains untouched.
Safe migration proceeds in stages — first synchronization in read mode, then writing for a limited set of products, and only then the full loop.
The rollback plan is described in advance: return points to the previous state, the procedure for disabling the exchange, and the preservation of accumulated data.
What about access and permissions?
We create separate accounts for the integration with the minimum required permissions — without access to payments and customers' personal data. Keys are stored in a secure vault, and rotation and revocation of access are performed without stopping the store.
What the client receives:
- a diagram of the integration with the current infrastructure and connection points;
- a list of exchange formats and rules for matching products and orders;
- a step-by-step plan for safe migration with checkpoints;
- a documented rollback plan and the procedure for returning to the previous state;
- an access matrix and a key storage policy;
- a regulation for monitoring exchange errors and notifications.
Describe your task and current stack — we will get back to you with an estimate and a work plan.
