Workflow

A no-code workflow for assigning AliExpress orders to eBay listings

The single most error-prone moment in a dropshipping day is the one where you connect an eBay sale to the AliExpress order you placed to fulfil it. Get it right and everything downstream — tracking, EDD, refund detection, profit — flows to the correct row. Get it wrong and you spend an hour later untangling whose tracking went where.

Most sellers do this matching in their head and their clipboard: open the eBay order, open the AE order, eyeball the SKU, copy the order ID, paste it into a sheet. It works until you are tired, or busy, or running three stores. You do not need to learn to code to fix this. You need a workflow that makes the match happen once, in seconds, and then never asks you to think about it again.

Why matching is harder than it looks

On paper it is "find the AE order for this eBay sale". In practice, several things conspire against you:

• One sale, several source orders. A buyer orders two variants and you place two AE orders. Now one eBay row needs to track multiple AliExpress orders without losing either.
• SKUs that almost match. Similar listings with near-identical SKUs make a copy-paste slip easy and invisible.
• Order-ID formats that fight your spreadsheet. Paste a 19-digit AE ID into a number cell and it rounds, silently pointing your row at the wrong order or none at all. We cover that trap in handling the 16-digit vs 19-digit AliExpress Order ID gotcha.
• Multiple stores and sources. Once Amazon, AliExpress, and MH orders are in play, "which source feeds this sale" needs a real answer, not a guess.

The goal is not to match faster by hand. The goal is to match once and let the SKU mapping carry every future order automatically.

The two-second, zero-code workflow

The principle is simple: tie the relationship to the SKU, not to each individual order. Do the thinking one time, per product, and let it apply forever:

1. Map the SKU to its source once. When you list or first fulfil a product, record which AliExpress (or Amazon, or MH) source it comes from. That is the entire "assignment" — done a single time per listing.
2. Let the order ID attach to the row. When a sale comes in, the AE order ID drops onto the matching row by SKU — no hunting, no clipboard relay.
3. Keep IDs as text. Store order IDs as plain text so long numbers never round. This is the one rule that quietly prevents the most wrong-row bugs.
4. Handle the multi-order case explicitly. When one sale needs two AE orders, the row should hold both, so tracking for each is captured rather than one overwriting the other.

Notice there is no scripting here. No Apps Script, no formulas you have to babysit, no webhook to maintain. The work is data entry you already do — listing a product — repurposed as the matching rule.

What the match unlocks

Once the source is assigned, every downstream task stops being manual:

• Tracking ID and the real carrier flow to the right row.
• The estimated delivery date lands where the buyer message will need it.
• Refund state attaches to the correct sale, so a refunded source order does not hide on the wrong line.
• True net profit can be computed per order, because the cost side is tied to the source you assigned.

In other words, the two seconds you spend assigning a SKU pays you back on every order that SKU ever sells.

Where Fetch Order Tracking fits

This is the workflow Fetch Order Tracking is built around. It splits Amazon, AliExpress, and MH orders by SKU, so the right source order maps to the right eBay sale without you relaying IDs by hand. It reads order IDs as text — both the 16-digit and 19-digit formats — so nothing rounds, and it keeps multi-order sales intact instead of letting one tracking number clobber another.

From there the tool does the rest automatically: it fetches each order's tracking ID, resolves the true carrier from the tracking-ID prefix (because AliExpress's carrier_name is unreliable), captures status, EDD, AE order amount, and refund state, and writes it all into the Google Sheet you already own. It runs in batches that auto-chain through roughly 25 orders per click with a skip-list so a run finishes in one go — the same engine described in why batch processing beats one-by-one for AE tracking calls.

You should be deciding what to list and how to price it, not playing clipboard tag between two browser tabs. Assign the SKU once, and let the rest run itself. Try Fetch Order Tracking and turn order matching from a daily chore into a one-time setup.

Frequently asked questions

Do I really need code to assign AliExpress orders to my eBay listings?

No. The whole point of this workflow is that the matching is data entry you already do, not scripting. You map each SKU to its source once when you list or first fulfil the product, and from then on the order ID attaches to the right row by SKU. There is no Apps Script, no formula to babysit, and no webhook to maintain.

How do I handle one eBay sale that needs two AliExpress orders?

Handle the multi-order case explicitly so the row holds both AE order IDs rather than letting one overwrite the other. If a single row can only store one source order, the tracking for the second order is lost and the buyer sees half their shipment. Fetch Order Tracking keeps multi-order sales intact, so tracking for each AliExpress order is captured against the same eBay sale.

Why does matching by SKU beat matching each order by hand?

Matching by hand relies on you being alert every single time, which fails when you are tired, busy, or running several stores. Tying the relationship to the SKU means you do the thinking once per product and every future order of that SKU inherits the mapping automatically. The two seconds spent assigning a SKU pays back on every order that SKU ever sells.

Related guides

• Handling the 16-digit vs 19-digit AliExpress Order ID gotcha
• The compound AE-order-ID pattern: one eBay order, many AliExpress orders
• Why batch processing beats one-by-one for AE tracking calls

---