AliExpress API

The compound AE-order-ID pattern: one eBay order, many AliExpress orders

Most order-tracking logic quietly assumes a clean one-to-one relationship: one eBay sale, one AliExpress order, one tracking number, one row. For a big chunk of your orders that assumption holds. And then a buyer orders two of something, or a multi-item listing, and your tidy model falls apart.

That single sale might map to two or three separate AliExpress orders, each with its own order ID, its own tracking number, and its own delivery timeline. If your sheet only has room for one, you are about to lose data. This is the compound AE-order-ID pattern, and handling it on purpose is the difference between a row you trust and a row that lies.

Why one eBay order becomes many AE orders

There are a few completely normal reasons a single eBay sale splits on the AliExpress side:

• Different suppliers. A multi-item listing or a buyer's combined order may need items from two different AE sellers, which means two orders by definition.
• Quantity limits. Some AE listings cap quantity per order, so a buyer wanting five units forces a split.
• Warehouse splits. The same supplier ships from two warehouses and AE creates child orders accordingly.
• Variation availability. One variation is in stock locally, another ships from China — different orders, different carriers, different ETAs.

None of these are edge cases you can ignore. At volume they show up every single day.

What naive tracking gets wrong

A naive setup stores a single AE order ID per row and fetches a single status. When the sale is actually compound, three things go wrong fast:

1. You only track one of the parcels, so the row says Delivered while the second parcel is still in transit, or never even shipped.
2. The AE order amount on the row is the cost of one parcel, not the true landed cost of the whole sale, so your profit math is off.
3. A refund on the second order never surfaces, because you are not even watching it.

A compound order that you treat as a single order is not a smaller problem. It is a row that confidently reports the wrong thing — which is worse than a blank cell, because you trust it.

The pattern that keeps the row correct

The fix is to treat the eBay order as the parent and the AE orders as a set of children, then roll the children up into the row's visible status. In practice:

• Store all AE order IDs together for the row — a compound field, not a single value. This is where you assign both order_ids once, and you are done.
• Fetch each child on every run, not just the first.
• Combine the statuses with the worst-case wins rule. If one parcel is delivered and one is still in transit, the row is In Transit, not Delivered. The buyer has not received everything, so neither has your status.
• Sum the AE amounts across children for true landed cost.
• Watch every child for refunds, because a refund on any one parcel affects the sale.

This is exactly how Fetch Order Tracking handles split orders. You assign the AliExpress orders that make up a sale, and from then on it fetches each one, combines the tracking, and writes a single honest status to the row in your Google Sheet. You still read one clean line; the tool does the rolling-up underneath.

Don't forget the carrier and refund quirks

Compound orders amplify two other gotchas. First, two parcels usually mean two different couriers, so you cannot assume one carrier for the row — and you definitely cannot trust the carrier name AliExpress hands you. That problem deserves its own attention, which is why we wrote why you should never trust AliExpress's carrier_name field on its own.

Second, refunds on one child can be silent. A cancelled second parcel may never flip the obvious fields, and if you are only watching the first order you will never see it. Proper refund detection has to run across every child order, not just the parent.

A quick checklist

1. Can your row hold more than one AE order ID? If not, fix that first.
2. Does your fetcher pull every child order on each run?
3. Does the row status reflect the least finished parcel?
4. Is the AE amount a sum, not a single value?
5. Is refund detection scanning all children?

Compound orders are not exotic — they are just the orders most tools forget to handle. Model the parent-and-children relationship once, and your sheet stays honest at any volume. If you would rather not build that logic yourself, Fetch Order Tracking already does it, so a split order looks exactly as calm on your sheet as a simple one.

Frequently asked questions

How do I show one status when an eBay order has several AliExpress parcels?

Combine the child statuses with a worst-case-wins rule. If one parcel is delivered and another is still in transit, the row should read In Transit, because the buyer has not received everything yet. The visible status should always reflect the least-finished parcel, so the row never claims the sale is complete before it actually is.

What should the AE order amount show for a split order?

It should be the sum of the amounts across all child orders, not the cost of a single parcel. If you only store one parcel's cost, your profit math is understated because part of your real landed cost is invisible. Summing the children gives you the true cost of fulfilling that one eBay sale.

Can Fetch Order Tracking handle one eBay order that needs two AliExpress orders?

Yes. You assign all the AliExpress orders that make up a sale once, and from then on it fetches each child on every run, combines the tracking, sums the amounts, and watches every child for refunds. The result is a single clean line in your Google Sheet, so a split order looks just as calm as a simple one-to-one order.

Related guides

• Handling the 16-digit vs 19-digit AliExpress Order ID gotcha
• Why you should never trust AliExpress's carrier_name field on its own
• Detecting refunds AliExpress reports as silent end_reasons

---