Collecting Temu Product Data

Temu is a client-rendered, app-first storefront. The HTML you receive is a shell, and the product data arrives afterwards as JSON. That changes the collection approach completely: parsing is not the hard part, finding the endpoint is.

Why the HTML is useless

Load a Temu product page and inspect the response body. It contains layout scaffolding, script tags and little else. The price, title, images and variants are fetched by the page's JavaScript after load.

Two consequences:

• An HTML parser gets nothing. Any selector-based approach fails on the first run.
• A headless browser works but is expensive, because you are loading and executing the full application for every record.

The efficient route is to read the network traffic the page generates and call the same endpoints directly. That is the same decision process as in Scraping Browsers Explained: render only when you must.

Finding the endpoints

The method is short and repeatable.

1. Open the product page in a browser with developer tools open, on the Network tab, filtered to XHR and Fetch.
2. Reload and watch the requests that return product data.
3. Identify the one whose response contains the price and title.
4. Note the URL, the required query parameters, the required headers, and any token or signature.
5. Replay it with a plain HTTP client and confirm you get the same JSON.

That last step is the one people skip and then regret. A request that works in the browser may carry a header or a signed parameter that a plain client cannot reproduce, and discovering that after writing the whole collector wastes a day.

What to expect in the JSON

Product responses typically contain price with currency, the discount structure, title, images, variant or SKU identifiers, rating and review aggregates, and shipping or region information. The exact shape is versioned and changes, so validate against a schema rather than assuming.

Two properties are worth capturing that HTML parsing would have missed:

Region. Temu localises pricing and availability by region, so the response carries region context and must be captured alongside the price.

Currency and formatting. The same numeric value means different amounts in different currencies, so the currency code is required on every record. The general argument is in E-Commerce Data Scraping.

The proxy requirement

Two independent needs, and mixing them up causes most failures.

Region correctness. Temu serves region-specific prices, so a collection through the wrong address returns the wrong region's data, and the price is not comparable. The address must be in the target region, which is the same requirement as any localised retailer, described in Proxies for SEO Monitoring for the search case.

Volume tolerance. The JSON endpoints are rate-limited per source, and hosting ranges are treated more harshly than consumer ranges. For sustained collection, residential addresses spread the load across many consumer sources, which is the standard answer in Residential Proxies for Price Monitoring.

A third, less obvious need: session handling. Some endpoints expect a session cookie set on an earlier page load. If they do, issue the sequence rather than calling the endpoint cold, and hold the session for the duration of the product group you are collecting.

Cadence and volume

Temu's catalogue is enormous, which makes full-marketplace collection impractical and unnecessary for most purposes. Decide what you actually need before choosing a cadence.

• Tracked products. A defined list at a daily or weekly cadence. Cheap and accurate.
• Category monitoring. New-product detection within a category, at whatever cadence the category turns over.
• Search result sampling. Price positioning within a query, sampled rather than exhaustive.

Attempting the whole catalogue means an enormous request count for data you will not use, plus a much higher chance of getting the address range throttled for everyone on it.

Handling blocks

When responses start returning challenges or empty payloads, the order of response is the same as anywhere else:

1. Slow down. Reduce concurrency before adding addresses.
2. Confirm the address is still in the right region, using the Proxy Checker and IP Lookup.
3. Rotate the pool if a subset of addresses has degraded, per What Is a Proxy Pool.
4. Replay the endpoint with the browser's exact headers if failures are consistent rather than rate-related.

Treating a block as a volume problem when it is a headers problem produces an escalating loop that ends with every address throttled.

Terms and personal data

Temu's terms restrict automated access, and the same constraints apply as for any retailer: keep rates human-plausible, do not create accounts for collection, and do not collect personal data. Product and price data is one thing; reviewer identities and order data are another, and the framework is in Data Collection Ethics for Engineering Teams.

For the broader method, see E-Commerce Data Scraping and Building an Amazon Price Tracker in Python. For the solution context, E-Commerce.