Case study

Why we built Fetch Order Tracking

We did not set out to build software. We set out to sell on eBay, source from AliExpress, and make a decent margin. The tool came later — out of frustration, the way most useful tools do.

This is the honest story of how Fetch Order Tracking happened: the evenings it was born from, the specific things that kept going wrong, and why we eventually decided to stop complaining and write the thing we wished already existed.

The 11pm copy-paste ritual

For the longest time, our tracking workflow was a person and two browser tabs. Open the eBay order. Find the matching AliExpress order. Copy the tracking number. Try to figure out which courier it actually was. Paste it all into a spreadsheet. Update the status by eye. Then do it again, three hundred-odd times a month.

It ate the end of every day. Call it about 45 minutes on a quiet night and a lot more when orders piled up. The work was not hard — it was just relentless, mechanical, and impossible to ever fully finish, because by the time you reached the bottom of the sheet the top had changed.

The worst part was not the time. It was the quiet certainty that somewhere in those three hundred rows, something was already wrong — a missed update, a stale status, a refund we had not noticed yet.

The three problems that actually hurt

As we kept at it, we realised our pain was not one big problem but three specific, recurring ones — and each had teeth.

1. The carrier was a guess. AliExpress would hand us a carrier_name that was vague or simply wrong, and we would upload the wrong courier to eBay. The truth, it turned out, was sitting in the tracking-ID prefix the whole time.
2. Refunds slipped past us. An order would show Delivered, we would mark it a win, and weeks later discover it had been refunded. One field was never enough to catch it.
3. Our profit numbers were fiction. We were subtracting a guessed eBay fee from the gross sale price and calling it margin. It was never the real number.

The moment we stopped guessing on fees

The profit one stung the most. We had been pulling prices from eBay's Order API, which gives you the gross amount the buyer paid, and then estimating fees. Then we found the Finances API — which reports the true net that actually hit the payout, fees already removed.

Switching to it was the first real "oh" moment. Suddenly the profit column matched the bank. We had been running the business on a number that was politely lying to us for months. If you have never made this switch, our piece on why eBay's Order API gives you the wrong earnings number is the one to read.

Building the tool we wished existed

So we built it for ourselves first. The brief was simple and selfish: never copy-paste a tracking number again, never guess a carrier again, never miss a refund again, and always see real profit.

It connects to eBay and to the AliExpress Dropshipping API and syncs everything into the Google Sheet we already owned — no new dashboard to learn, no data held hostage. For every order it pulls the tracking ID, the carrier (resolved properly from the prefix, not the unreliable field), the tracking status, the estimated delivery date, the AE order amount, the refund state, a carrier delivery-proof link, and the AE order date.

A few decisions we are still proud of:

• Real refund detection. It checks issue_status, the gmt_refund_* timestamps, and child orders together, so a delivered-then-refunded order can no longer hide. We wrote up the approach in dropshipping refund detection.
• Batch processing that finishes. Around 25 orders a click with a short delay, auto-chaining to the next batch, and a skip-list so it never loops the same rows. A run starts and actually ends.
• One workspace, many stores. Because we ran more than one region, it handles eBay UK, US, and AU side by side.

What it gives you back

The day the first full sync ran clean, the 11pm ritual just... stopped. The sheet filled itself, the carriers were right, the refunds were flagged, and the profit column finally told the truth. That feeling — opening a sheet that is already correct — is the whole product.

We are still eBay × AliExpress sellers. We use Fetch Order Tracking on our own stores every day, which is the only reason it keeps getting the small details right. It pays for itself the way we always hoped it would: in hours not spent copy-pasting and in money not lost to wrong carriers, missed refunds, and fictional margins.

If any of this sounded like your evenings, it was built for you too. Try Fetch Order Tracking — and get your nights back.

Frequently asked questions

What problem does Fetch Order Tracking solve?

It ends the manual tracking ritual of opening each eBay order, finding the matching AliExpress order, copying the tracking number, guessing the courier, and pasting it into a spreadsheet. We built it after that work was eating roughly 45 minutes a night and still letting carriers, refunds, and profit numbers slip. It fetches and syncs all of it for you instead.

What does it actually fetch for each order?

For every order it pulls the tracking ID, the carrier resolved properly from the tracking-ID prefix rather than the unreliable field, the tracking status, the estimated delivery date, the AE order amount, the refund state, a carrier delivery-proof link, and the AE order date. It reads true net earnings from eBay's Finances API, so the profit column matches your bank.

Where does the data go, and do I have to learn a new dashboard?

No. It syncs everything into the Google Sheet you already own, so there is no separate dashboard to learn and no data held hostage. Batch processing clears around 25 orders a click with auto-chaining and a skip-list, so a run starts and actually finishes instead of looping the same rows.

Related guides

• Why eBay's Order API gives you the wrong earnings number
• Refunds you didn't see: catching cancellations on already-delivered orders
• Why you should never trust AliExpress's carrier_name field on its own

---