AliExpress API

Handling the 16-digit vs 19-digit AliExpress Order ID gotcha

April 27, 2026 · 5 min read

Key takeaways

AliExpress issues order IDs in two formats — older 16-digit numbers and newer 19-digit ones — and both are valid in the same account on the same day.
A 19-digit order ID exceeds the precision of a spreadsheet cell or an integer variable, so it silently rounds and points your sync at the wrong order or none at all.
Always store and send the order ID as text, never as a number, from the cell to the variable to the API payload.
A mangled ID rarely throws an error — it returns an empty or wrong result, so the dropped order stays invisible until a buyer complains.
Fetch Order Tracking reads IDs as text and accepts both formats, so a mixed batch of old and new orders syncs in one pass without silent drops.

You paste an AliExpress order ID into your sheet, run your tracking sync, and most rows light up with carrier, status, and an EDD. But a handful sit there blank — no error, no status, nothing. You assume the order just has not shipped yet. A week later a buyer opens an Item Not Received case and you discover the order did ship; your sync simply never read it.

Nine times out of ten, the culprit is the order-ID format. AliExpress does not hand every order the same shape of identifier, and if your parser assumes one shape, it quietly drops the rest. This is one of the cheapest bugs to fix and one of the most expensive to ignore.

Why AliExpress orders come in two lengths

For years, AE order numbers were 16 digits. As volume grew, newer orders started arriving as 19-digit numbers. Both are valid, both are live, and you will see a mix in the same account on the same day depending on when and how the order was placed. There is no flag that tells you which one you are looking at — you just get a number.

The problem is not the length itself. The problem is what happens around it:

Spreadsheet rounding. A 19-digit number exceeds the precision a cell stores as a number. Google Sheets and Excel happily turn 4012345678901234567 into 4012345678901230000 or even scientific notation. Now the ID you send to the API does not exist.
Type coercion in code. If your script reads the ID as an integer, the same precision loss happens silently. JavaScript's Number cannot hold a 19-digit integer exactly, so the last few digits drift.
Truncated copy-paste. Pasting from a confirmation email or the AE seller panel sometimes clips trailing digits, especially across the 16/19 boundary.

The order ID is not a number. It is a string of digits that happens to look like a number. Treat it as text everywhere — the cell, the variable, the API payload — and most of the gotcha disappears.

What actually breaks in the API response

When you call the AliExpress Dropshipping API with a mangled ID, you rarely get a clean "not found" you can branch on. Instead you get one of these, each of which looks like "nothing happened":

An empty result set, because the ID does not match any record.
A different order entirely, because a rounded ID collided with a real one (rare, but it happens, and it is the worst case — wrong tracking on the wrong row).
A response shape that differs subtly between order types, so a field your parser expects is nested one level deeper and reads as null.

None of these throw. Your run finishes, the dashboard says "done", and the gap only shows up when a buyer complains. That is why this bug feels invisible until it costs you a defect.

The safe parser

You do not need anything clever — you need discipline. The rules that catch every case:

Store IDs as text. In Google Sheets, format the column as Plain text before any data lands, or prefix with an apostrophe. In code, never cast to int or Number; keep it a string from read to request.
Validate length and characters. Accept 16 or 19 digits, all numeric, nothing else. Anything outside that range gets flagged for review, not sent blind.
Trim invisibly. Strip leading and trailing whitespace and stray non-breaking spaces that sneak in from copy-paste.
Branch on response shape, not assumptions. Read the status fields defensively so a deeper-nested value for one order type still resolves. (We cover those fields in our guide on the raw order_status and logistics_status fields.)

Why this matters more at volume

At 30 orders a month, a couple of dropped rows is an annoyance you might catch by eye. At 300 or 3,000, you will never spot the blanks manually — they hide in the scroll. The format split does not announce itself; it just shaves a small, steady percentage off your tracking coverage, and every uncovered order is a candidate for a late-shipment ding or an INR case.

This is exactly the kind of edge case Fetch Order Tracking handles so you never think about it. It reads order IDs as text, accepts both the 16-digit and 19-digit formats, and parses each response by its actual shape — so a mixed batch of old and new orders syncs cleanly in one pass. No rounding, no scientific notation, no silent drops. The same defensive batching that auto-chains through hundreds of orders is described in why batch processing beats one-by-one.

If you would rather not maintain a parser that quietly rots every time AliExpress tweaks a response, let the tool own it. Try Fetch Order Tracking and watch the blank rows disappear from your next sync.

Frequently asked questions

How can I tell whether an AliExpress order ID is the 16-digit or 19-digit format?

You usually cannot tell from a flag, because AliExpress does not mark which format an order uses — you simply get a string of digits. The practical answer is that you do not need to tell them apart: accept both lengths, treat the ID as text, and let your parser handle a 16-digit or 19-digit value the same way. Validating that the value is all numeric and either 16 or 19 digits long is enough to catch corrupted IDs before you send them.

Why does my 19-digit AliExpress order ID change when I paste it into Google Sheets?

Google Sheets and Excel store numbers with limited precision, so a 19-digit value gets rounded to something like 4012345678901230000 or shown in scientific notation. The fix is to format the column as Plain text before any data lands, or prefix the value with an apostrophe. Once the cell treats the ID as text, the digits stop drifting and your sync queries the order that actually exists.

Why do some orders sync fine while a few stay blank with no error?

A mangled or rounded order ID rarely returns a clean not-found you can branch on. Instead the API hands back an empty result or a different order, so the run finishes, the dashboard says done, and the gap only surfaces when a buyer opens a case. Reading IDs as text and parsing each response by its actual shape — which is what Fetch Order Tracking does — removes the silent drops.

Related guides

Try Fetch Order Tracking → More guides