AliExpress API

Reading the raw AliExpress order_status and logistics_status fields

May 23, 2026 · 7 min read

Key takeaways

order_status describes the commercial state of the transaction, while logistics_status describes the physical state of the parcel, and the two routinely disagree.
WAIT_BUYER_ACCEPT_GOODS does not mean delivered; it means the parcel is in transit and the buyer has not confirmed receipt, which most buyers never do.
BUYER_ACCEPT_GOODS can be auto-triggered on a timer, so it can mark an order accepted even when the buyer never saw the parcel.
A clean sheet status comes from folding both raw fields, plus the refund signals, into one human-readable value rather than showing raw enum strings.
Fetch Order Tracking reads both fields and the refund signals, resolves the carrier from the tracking-ID prefix, and writes one clean status per row.

Every tracking decision you make — what to tell a buyer, when to upload a number to eBay, whether to chase a refund — comes down to two fields buried in the AliExpress Dropshipping API response: order_status and logistics_status. Get them right and your sheet practically writes itself. Misread them and you'll mark orders shipped that haven't left the warehouse.

The trouble is that AliExpress documents these fields thinly and returns more values than any tutorial lists. Here's a working seller's map of what they actually mean and how to collapse them into a clean status your sheet (and your buyers) can trust.

The two fields do different jobs

It helps to remember what each field is for:

order_status describes the commercial state of the order — has it been placed, paid, shipped, finished, or closed? It's about the transaction.
logistics_status describes the physical state of the parcel — where is it in the carrier network right now?

You need both because they routinely disagree, and the disagreements are where the useful information lives.

The order_status values you'll actually see

The common order_status values, roughly in lifecycle order:

PLACE_ORDER_SUCCESS — order created, often not yet paid or just paid. Nothing has shipped.
WAIT_SELLER_SEND_GOODS — paid, supplier hasn't dispatched. This is your “Awaiting Dispatch” territory.
SELLER_PART_SEND_GOODS — partial shipment, common on split orders.
WAIT_BUYER_ACCEPT_GOODS — shipped and in transit; the buyer hasn't confirmed receipt.
FUND_PROCESSING / FINISH — order completed.
IN_CANCEL / CANCEL — cancellation in progress or done — a strong refund signal.

WAIT_BUYER_ACCEPT_GOODS is the one people misread. It does not mean delivered. It means the parcel is out and the buyer hasn't clicked “confirm received” — which most buyers never do. Lean on logistics_status for actual delivery.

The logistics_status values that matter

On the parcel side you'll meet values like:

NO_LOGISTICS — no tracking yet. Don't upload anything to eBay.
SELLER_SEND_GOODS — supplier marked it shipped; a tracking ID should now exist.
BUYER_ACCEPT_GOODS — system considers it received/closed (often auto-triggered after a window, not because the buyer confirmed).
Carrier-level in-transit and delivered states surfaced through the tracking sub-object.

The dangerous one is BUYER_ACCEPT_GOODS — it can mark an order “accepted” on a timer even when the buyer never saw the parcel. We unpack that trap in what BUYER_ACCEPT_GOODS really means in the AliExpress response.

Mapping raw values to a clean sheet status

You don't want raw enum strings in front of you all day. The point is to fold both fields into one human status. A sane mapping looks like this:

WAIT_SELLER_SEND_GOODS + NO_LOGISTICS → Awaiting Dispatch
WAIT_BUYER_ACCEPT_GOODS + in-transit logistics → Shipped / In Transit
any state + delivered logistics → Delivered
CANCEL / refund signals → Cancelled & Refunded
past EDD with no movement → Expired / Investigate

Notice that several different raw states all collapse to “Shipped” — that consolidation is deliberate and worth doing carefully. We list the ones that should all read as one thing in seven tracking statuses that should map to Shipped in your sheet.

Why one field is never enough

If you trust only order_status, you'll miss parcels that physically delivered while the order sat “waiting for buyer” forever. If you trust only logistics_status, you'll miss cancellations and refunds that show up commercially before the carrier data catches up. And neither field alone catches a delivered-then-refunded order — you only see that by reading the commercial state, the logistics state, and the refund fields together.

That cross-checking is fiddly to build and even fiddlier to keep working as AliExpress quietly adds or renames enum values. It's exactly the kind of logic Fetch Order Tracking maintains for you: it reads both raw fields plus the refund signals, resolves the real carrier from the tracking-ID prefix, and writes a single clean status to your Google Sheet — so you read “Delivered” instead of decoding WAIT_BUYER_ACCEPT_GOODS at 11pm.

Build the map once, or let it be maintained for you

If you're rolling your own, write the mapping table down, version it, and test it against real orders in every state before you trust it — an undocumented enum value that falls through your switch as “unknown” is how orders silently go stale.

Or skip the maintenance entirely. Fetch Order Tracking keeps the mapping current against both APIs and gives you the clean status, the carrier, the EDD, and the refund state on every row, automatically. The raw fields are powerful — you just shouldn't have to babysit them.

Frequently asked questions

What is the difference between order_status and logistics_status?

order_status describes the commercial state of the order, such as whether it has been placed, paid, shipped, finished, or cancelled. logistics_status describes the physical state of the parcel, meaning where it sits in the carrier network right now. You need both because they often disagree, and those disagreements are where the useful information lives.

Does WAIT_BUYER_ACCEPT_GOODS mean the parcel was delivered?

No, and this is the value people misread most. It means the parcel is out and in transit and the buyer has not clicked confirm received, which the vast majority of buyers never do. For actual delivery you should lean on logistics_status and the carrier-level delivered state, not on order_status alone.

How should I map these raw values to a clean status in my sheet?

Fold both fields into one human status: WAIT_SELLER_SEND_GOODS with NO_LOGISTICS becomes Awaiting Dispatch, an in-transit logistics state becomes Shipped, any state with delivered logistics becomes Delivered, and a CANCEL or refund signal becomes Cancelled and Refunded. Write the mapping down, version it, and test it against real orders in every state. Fetch Order Tracking maintains this mapping for you and writes a single clean status per row.

Related guides

Try Fetch Order Tracking → More guides