Automation

Why batch processing beats one-by-one for AE tracking calls

May 7, 2026 · 5 min read

Key takeaways

Processing AliExpress orders one at a time is both slow (20 to 40 seconds each) and fragile, because the workflow has no memory of what is already done.
Batch processing works your pending orders as a set: it paces itself under the AE rate limit, skips terminal orders, and produces repeatable results.
Auto-chaining is what turns batching into a single click — it processes a chunk of about 25 orders, waits for the rate-limit delay, then starts the next chunk on its own until the queue is empty.
A skip-list that excludes Delivered, Cancelled, and Refunded orders is what keeps a run from looping over the same rows forever.
Fetch Order Tracking clears your whole order book from one click by chaining ~25-order cycles with a built-in delay and a skip-list.

If you have ever sat there clicking a tracking link for one order, copying the status, pasting it into a cell, then scrolling down and doing it again, you already know the problem. It is not that any single lookup is hard. It is that there are hundreds of them, and the work never ends because tomorrow there are hundreds more.

One-by-one tracking is the default that everyone falls into, and it is the first thing that breaks when you grow. Let's talk about why batch processing wins, and what a sane batch system actually looks like in practice.

One-by-one is slow and fragile

The obvious cost of processing orders one at a time is speed. A human checking and updating a single AliExpress order takes maybe 20 to 40 seconds once you count the scroll, the lookup, and the paste. At 300 orders a month that is real hours. But speed is only half the story.

The bigger problem is fragility. A one-by-one workflow has no memory. If you get interrupted at order 140, you do not reliably know where to restart. You re-check rows you already finished, you skip rows you meant to do, and terminal orders that are already Delivered or Cancelled get re-opened again and again. Every manual touch is a chance to paste the wrong tracking ID into the wrong row.

The real enemy is not slow lookups. It is a process with no memory, where every interruption costs you accuracy and every order can be touched twice.

What batching actually fixes

Batch processing groups your pending orders and works them as a set, not as a list you babysit. A good batch run does three things a manual loop cannot:

It paces itself. A fixed delay between calls (we use about 1.5 seconds) keeps you under the AliExpress API frequency limits instead of hammering them and getting throttled mid-run.
It remembers what is done. A skip-list means a row that already reached a terminal state is never re-fetched. The working set shrinks as you go.
It is repeatable. The same run on the same data gives the same result, so you can trust the column instead of double-checking it.

Auto-chaining: the part that makes it one click

Plenty of tools claim to batch but still make you click once per chunk. That is better than one-by-one, but it is not done. The version that actually saves your morning is auto-chaining: process a chunk of roughly 25 orders, pause for the rate-limit delay, then automatically start the next chunk, and the next, until the queue is empty.

This is exactly how Fetch Order Tracking runs. You click once. It processes about 25 orders per cycle with a built-in delay, then chains into the next cycle on its own. A JavaScript skip-list keeps it from looping the same rows, so the run finishes in one pass instead of grinding over the same 25 orders forever. If you have ever watched a sync re-process the same block on repeat, that exact failure mode is covered in why your auto-update keeps looping on the same 25 rows.

The math, framed honestly

Take a store doing, say, 300 orders a month. Done by hand at 30 seconds each, that is around 2.5 hours of pure clicking, spread across the month as a daily chore you resent. A chained batch run clears the same queue while you make coffee, and it does not skip, double-up, or fat-finger a tracking number into the wrong cell.

The accuracy gain is the part people undersell. Every tracking number that lands in the right row on time protects your eBay metrics. Missed and late updates quietly hurt you, which is the whole argument in automating the eBay to AliExpress sync end to end rather than treating tracking as a manual side task.

What to look for in a batch system

A real delay between calls so you respect AE rate limits.
A skip-list that excludes terminal statuses like Delivered, Cancelled, and Refunded.
Auto-chaining so one click clears the whole queue.
Writes that go straight into the Google Sheet you already own, not a separate dashboard you have to reconcile.

Tracking is not the work that makes you money. It is the work that protects the money you already made. Batching with auto-chaining turns it from a daily grind into a single click, and Fetch Order Tracking is built to do exactly that across your whole order book. Once you stop touching orders one at a time, you stop making one-at-a-time mistakes.

Frequently asked questions

How many AliExpress orders can a batch run process in one click?

With auto-chaining there is no fixed ceiling per click — the system processes a chunk of about 25 orders, pauses for the rate-limit delay, then automatically starts the next chunk and keeps going until the queue is empty. So a single click can clear hundreds of pending orders in one pass. Fetch Order Tracking works exactly this way, chaining ~25-order cycles until nothing is left to fetch.

Will batching too fast get me throttled by the AliExpress API?

It can, which is why a good batch system paces itself with a fixed delay between calls rather than firing requests as fast as possible. We use a delay of about 1.5 seconds, which keeps you comfortably under the AE frequency limits while still clearing the queue quickly. The point of batching is not raw speed; it is finishing the whole set reliably without tripping a rate limit mid-run.

Why does my batch run keep re-checking orders that are already delivered?

That is the symptom of a missing or broken skip-list. Without one, the run has no memory of which rows reached a terminal state, so Delivered, Cancelled, and Refunded orders get re-fetched every cycle and the run never shrinks its working set. A proper skip-list excludes those terminal statuses so each pass is smaller than the last and the run actually finishes.

Related guides

Try Fetch Order Tracking → More guides