Singles' Day Price Tracking on AliExpress: An Agent Walkthrough

An AliExpress price tracker for Singles' Day does not need a browser extension. It needs a list of products, a lookup that returns the current price as data, a place to store each reading and a comparison between runs. This walkthrough builds that loop as an agent or a cron job that calls two NeuralVerge sources, over API or MCP, around the 11 November sale. It uses a real request and response, shows the cost per check and is honest about what the sources do not do.

The short version

• —What you build: a watch list, a scheduled lookup, a table of timestamped readings and a diff that decides what is worth an alert. The scheduling and the alert are yours; the source only returns the listing.
• —What reads the prices: the AliExpress product source takes a product ID or URL and returns title, price, currency, store and more. The AliExpress product search source finds IDs by keyword and returns price and original price.
• —What it costs: 5 points per product lookup and 1 point per record returned by a search, according to the source pages. A lookup that does not resolve is not billed.
• —Who it is for: resellers, dropshippers, buyers with a shopping list and anyone giving an assistant a "check this listing" tool before 11 November.
• —What it is not: a built-in alerting product. There is no scheduler or notification inside the sources, so you bring a cron job, a queue worker or an agent that wakes up on a timer.

Why Singles' Day needs a tracker

Singles' Day falls on 11 November. For anyone buying or reselling from AliExpress it is the one week in the year when prices move a lot and a lot of listings change at once. A price you saw on the first of the month may not be the price on the day, in either direction.

A tracker answers three questions that a glance at the page cannot. What was the price before the sale started? What is it now? And did it ever go lower, or did it only look lower next to a crossed-out figure? The third question is the one that matters most, and you can only answer it if you stored the readings.

Why a history beats a label

A listing can show a pre-discount price next to the current one. That figure is whatever the listing publishes. It tells you what the seller wants you to compare against, not what the product sold for last month. Your own stored readings are the only comparison you control. If you start taking readings now, a week or two before the sale, you will have a baseline by 11 November.

What the sources can and cannot see

Both sources read the public listing when you make the request. That has consequences you should plan for:

• —The price is a moment in time. It can change right after the reading.
• —A sale shorter than your check interval can be missed entirely.
• —The price is the listing price. Shipping at checkout, coupons, platform vouchers and tax are outside it. The product response has a shipping field, but the source page says it is filled only when the listing publishes shipping details, and the sample response shows it as null.
• —Listing detail varies by store and by locale, as it does on the site itself.

How the tracker works

Five steps, each with a different failure mode. Keep them separate in code.

1. Build the watch list

A watch list is a table with one row per product: your internal name, the AliExpress product ID, the language and currency you will always read it in, and a target price if you have one. If you already have product URLs, you can store those instead, because the product source accepts either an ID or a URL.

If you do not have IDs yet, use search once to find candidates. The search source takes a keyword and optional filters: sort, price range, shipping origin and destination, free shipping, AliExpress Choice, four-star-and-up and local shipping. Search costs 1 point per record returned, so a search for 25 results costs 25 points. A human or a rule picks the listings worth watching, and those IDs go on the watch list. Do not re-run the matching on every check.

2. Read each listing on a schedule

On each run the tracker takes every row that is due and sends one product request. The scheduler is whatever you already have: a cron entry, a queue worker, a GitHub Actions workflow, or an agent that wakes on a timer. The sources do not schedule anything for you.

Fix the locale. If you read a product with currency set to USD today, read it with USD tomorrow. The product source page says language and currency control the site locale the listing is read in, and that the same product can be worded and priced differently by locale. Changing them between runs creates fake price changes.

3. Store every reading

Write each result to a table, even when nothing changed. A flat line is information too. A minimal row looks like this:

def to_reading(product, checked_at, locale):
    p = product["machine"]["product"]
    return {
        "product_id": p["id"],
        "checked_at": checked_at,
        "locale": locale,                 # e.g. "en_US/USD", fixed per product
        "price": p["price"],
        "currency": p["currency"],
        "title": p["product_title"],
        "store_id": (p["store"] or {}).get("id"),
        "sold_text": p["sold_text"],      # e.g. "6 sold", as shown on the listing
        "resolved": True,
    }

If a lookup does not resolve, store a row with resolved set to false and no price. Do not store zero.

4. Diff against the last reading and the baseline

Compare each new reading with two things: the previous reading and the baseline, which is the lowest price in your stored history before the sale window opens. The comparison is where the decisions live:

• —Price change since the last run. The obvious signal.
• —Distance from the baseline. A price that is 10% under your pre-sale low is more interesting than one that is 40% under a crossed-out figure.
• —Store change. If the store block shows a different store id at a lower price, you are looking at a different seller, not a price drop.
• —Title change. Titles on these listings are long and can change. A different title at a different price may be a different variant.

def classify(new, last, baseline, drop_pct=10):
    if not new["resolved"]:
        return "unknown"
    if last is None:
        return "first reading"
    if new["store_id"] != last["store_id"]:
        return "seller changed"
    if new["price"] < baseline * (1 - drop_pct / 100):
        return "below pre-sale low"
    if new["price"] < last["price"]:
        return "dropped"
    if new["price"] > last["price"]:
        return "rose"
    return "unchanged"

5. Alert with context

"Price changed" is not enough. Send the old and new price, the baseline, the store name and the product URL, so a person can decide in a few seconds. Send a crossing of your target price immediately and batch everything else into a daily digest. How you send it is your choice. Nothing in the sources sends messages.

REST and MCP

The tracker can read AliExpress over REST from your backend, or over MCP when the caller is an assistant that picks its own tools. It is the same source and the same JSON either way. AI research is the only part of the platform that is REST-only. Replace YOUR_API_KEY with your key, and see docs.neuralverge.ai for endpoint and parameter details.

One product lookup over REST

This is the request shown on the AliExpress product source page:

curl -X POST https://api.neuralverge.ai/functions/v1/run-aliexpress-product \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "product": "1005012791281455", "language": "en_US", "currency": "USD" }'

The JSON below is the sample response from the source page. To keep it readable I removed the diagnostics block, which holds page-fragment debugging text and is not needed for a tracker. Every other field and value is as shown on the source page.

{
  "session_id": "11111111-1111-1111-1111-111111111111",
  "kind": "aliexpress_product",
  "product": "1005012791281455",
  "language": null,
  "currency": null,
  "human": "# AliExpress product\n\n- **Product:** 1005012791281455\n- **Proxy traffic:** 1.51 MB\n- **Title:** EPOMAKER NEX Lite Tri-Mode Wireless Gaming Mouse PAW3311 12000 DPI 1000Hz RGB Charging Dock for PC Mac Gaming Office - AliExpress 7\n- **Price:** USD48.38\n- **Store:** Virtdream Store",
  "machine": {
    "product": {
      "id": "1005012791281455",
      "product_url": "https://www.aliexpress.us/item/3256812604966703.html?gatewayAdapt=4itemAdapt",
      "product_title": "EPOMAKER NEX Lite Tri-Mode Wireless Gaming Mouse PAW3311 12000 DPI 1000Hz RGB Charging Dock for PC Mac Gaming Office - AliExpress 7",
      "image": "https://ae-pic-a1.aliexpress-media.com/kf/Sff1d5d4c796e423e8f2a12aa0b6ba80fm.png",
      "images": [
        "https://ae-pic-a1.aliexpress-media.com/kf/Sff1d5d4c796e423e8f2a12aa0b6ba80fm.png",
        "https://ae-pic-a1.aliexpress-media.com/kf/S724cb8c7693b4d23b425c0abf397784ft.png"
      ],
      "price": 48.38,
      "currency": "USD",
      "rating": null,
      "review_count": null,
      "sold_text": "6 sold",
      "max_purchase_quantity": null,
      "category_ids": [],
      "store": {
        "@type": "AliexpressProductStore",
        "id": "1104267285",
        "name": "Virtdream Store",
        "url": "https://www.aliexpress.com/store/1104267285",
        "image": null,
        "positive_rate": null,
        "feedback_count": null
      },
      "shipping": null,
      "skus": []
    },
    "proxy_traffic_bytes": 1583480,
    "diagnostics": { "...": "removed" }
  },
  "total_points": 5
}

Reading the response as a tracker

• —price and currency. 48.38 USD is the number you store, together with the locale you asked for. In the sample the top-level language and currency echo as null, so keep your own record of the values you sent.
• —store.id. Compare it between runs to catch a change of seller.
• —sold_text. The orders-sold text as the listing shows it, here "6 sold". It is text, not a number, so store it as is.
• —rating, review_count, shipping, skus. Present in the shape, but empty in this sample. The source page says they are filled when the listing publishes them. Handle null as unknown.
• —product_url. The sample's URL carries a different numeric item path from the ID, so identify the product by id and use the URL only as a link for people.
• —total_points. The lookup cost 5 points.

Finding products by keyword

For discovery, the search source takes a keyword and returns price and original price per result. This is the request from its source page:

curl -X POST https://api.neuralverge.ai/functions/v1/run-aliexpress-product-search \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "keyword": "wireless mouse", "max_items": 25, "sort": "orders", "country": "US" }'

The source page's captured sample used max_items set to 2 and returned two records at 2 points. One of its items, shortened here to the fields a tracker needs, looks like this:

{
  "id": "3256812660562508",
  "product_title": "Ultra Light Gaming Mouse Wireless 59g 12000DPI 3-Mode Connection ...",
  "price": 12.41,
  "price_text": "$12.41",
  "original_price": 54.35,
  "original_price_text": "$54.35",
  "currency": null
}

Note that currency is null in that sample, so a search result is a good way to find candidates and a poor basis for a price history on its own. Take the reading itself from the product lookup, with the locale pinned.

The same lookups over MCP

Through the hosted MCP server at https://mcp.neuralverge.ai/mcp, the same two lookups are the tools run_aliexpress_product and run_aliexpress_product_search, with the same arguments: product, language and currency for the first; keyword, max_items, sort and country for the second. The REST paths use hyphens (run-aliexpress-product), the tool names use underscores. Setup for Claude and other clients is covered in the MCP server guide.

A sensible split is REST for the scheduled loop, where you control the cadence and the storage, and MCP for the question a person asks an assistant on the day: "what is this listing at right now, and what did we see last week?" For the second, give the assistant read access to your readings table as well, so it can compare.

Cost and limits

Cost is easy to estimate because the unit prices are fixed on the source pages: 5 points per resolved product lookup and 1 point per search record returned. The plans on the pricing page are the reference for what a point costs on your plan.

Billing is stated on the source pages: the product source charges only when the product resolves, and the search source charges per record actually returned, so a search that matches nothing costs nothing. Do not assume that holds for sources not listed here; check each page.

A worked example

Say Acme Oy, a Finnish online shop, wants to watch 50 AliExpress products from 4 November to 17 November, one check a day. That is 14 days of 50 lookups, 700 lookups in all, and 700 times 5 is 3,500 points. Add one discovery search of 100 records, 100 points. On the three days around 11 November it checks every six hours instead, which is 3 extra days of 150 extra lookups a day, so 450 more lookups and 2,250 more points. The total is about 5,850 points. Cost scales with products times checks times 5, and you control all three.

To keep it down, check slowly in the weeks before the sale and fast only in the window where prices move. Use search to discover, then look up by ID.

Pitfalls

A different locale looks like a different price. Pin language and currency per product and never change them mid-history. If you must change them, start a new series.

Variants hide behind one product. The product response has a skus array for variants, which the source page says is filled when the listing has them. In the sample it is empty, and the price you get is for the listing as the page presents it. If a product has colors or sizes at different prices, test one before you trust a series.

A flash sale shorter than your interval is invisible. You are sampling, not streaming. Shorten the interval in the days you care about, and accept that you may miss a short window.

Search results are not a price history. Search gives you an original price and a current price at one moment. The original_price is whatever the listing shows. Use it as a hint, and use your own readings as the record.

A broad search can come back partial. The search source page says a filter-light query can hit the time budget and return partial: true with the records collected so far. Narrow the query or lower max_items, as the page suggests.

How to decide

Before you build on this, or on any price source, answer these:

1. —Is a timed sample enough? If you need every second of a flash sale, this is the wrong shape. If a few checks a day is fine, it fits.
2. —Can you identify each product by ID? If you only have vague descriptions, spend a search run to find them first.
3. —Which locale will you read each product in? Pick language and currency once, and write them in the watch list.
4. —What counts as an alert? Decide your drop threshold, your baseline window and whether a seller change should alert.
5. —What does it cost at your cadence? Multiply products by checks by 5 points, then add your discovery searches.
6. —Where do you run the loop? Cron or a worker for the schedule, an agent for the conversational layer. The sources do not schedule for you.
7. —Which workflow is yours? The ones that fit best:
   • —Reseller sourcing: watch the cost of the items you plan to resell and buy when a price falls below your baseline.
   • —Personal shopping list: a person tells an assistant what they want, and the agent reports on 11 November which items are under target.
   • —Dropshipping catalog: check that the supplier prices behind your listings have not moved enough to erase your margin.
   • —Deal verification: compare the advertised markdown with your own history before you tell customers it is a deal.

If you also track other marketplaces, the same loop works with other product sources. The price monitoring agent post builds it for Amazon, Walmart and Target, where each retailer returns a slightly different shape that the agent normalizes into one record.

Frequently asked questions

Does NeuralVerge send me an alert when an AliExpress price drops?

No. The AliExpress sources return the listing as it is at the moment you ask. Scheduling, storing readings and comparing them is done by your own agent or cron job, which then sends the alert through whatever channel you already use.

How much does it cost to track 50 products through Singles' Day?

A product lookup costs 5 points and a search costs 1 point per record returned, according to the source pages. Fifty products checked once a day for 14 days is 700 lookups, or 3,500 points. Checking every six hours is four times that.

Can I track the price in my own currency?

Yes. The product source takes optional language and currency parameters that control the site locale the listing is read in. Use the same values on every run, otherwise a change in the number may be a change in locale and not a change in price.

Can I use this from an AI agent through MCP?

Yes. AliExpress product and AliExpress product search are available over REST and as MCP tools (run_aliexpress_product and run_aliexpress_product_search), with the same arguments on both routes. An assistant can answer a one-off "what is this listing now?" question directly, while a scheduled loop usually calls REST.

How do I know a Singles' Day discount is real?

Compare against your own history. The search source returns an original price when an item is on sale, but that figure is whatever the listing shows. If your stored readings from the weeks before the sale are close to the current price, the markdown is smaller than the label suggests.

What if a product disappears or the lookup fails?

A product ID or URL that does not resolve is not billed, according to the source page. Your tracker should record the miss with a timestamp, treat it as unknown and not as a price of zero, and retry on the next run.