Walmart Scraper - Products, Prices, Ratings, Sellers avatar

Walmart Scraper - Products, Prices, Ratings, Sellers

Pricing

Pay per event

Go to Apify Store
Walmart Scraper - Products, Prices, Ratings, Sellers

Walmart Scraper - Products, Prices, Ratings, Sellers

Search Walmart and get products as clean rows: title, brand, model, UPC, category, rating, review count, availability, seller and the real current price from each product page. No browser and no CAPTCHA solving on your side.

Pricing

Pay per event

Rating

0.0

(0)

Developer

SR

SR

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

10 hours ago

Last modified

Share

Walmart Scraper

Search Walmart and get products back as rows: name, brand, rating, review count, availability, seller, and optionally the real current price from each product's own page.

No browser, no CAPTCHA solver.

What you get

  • Products from the search and category pages, about 60 per page, with rating and review count on nearly every row
  • The barcode (UPC) on every detailed row. Walmart publishes it on the product page, and it is an exact join key against any other catalogue: match a Walmart listing to a Beslist, Discogs or Amazon record without fuzzy title matching
  • Price, brand, seller, category path and description, all from each product's own page. Walmart serves none of them in search results, so they come with the detail stage
  • Prices that belong to the right product. A Walmart product page carries dozens of price blocks: variants, bundles, "similar items" and sponsored rails. This actor anchors on the product's own id and refuses to reach beyond a bounded window, so a row either gets its own price or none at all
  • was_price where there is a genuine markdown, filtered so it must be above the current price
  • Sponsored placements flagged rather than mixed in silently
  • price_source on every priced row, saying whether the number was found next to this product's id or elsewhere on its page

Two things worth knowing before you run it

Walmart answers HTTP 200 to everything, including to requests it refuses, where the body is a 15 KB "Robot or human?" page. Judging this site by status code alone says it is wide open; judging by size alone says it is closed. Both are wrong, which is why this Actor scores success on the product data itself.

The search payload has its prices removed. A successful request returns the full product list with names, brands, ratings and review counts, and price: 0 with an empty price block on every single product. This is Walmart's choice, not a parsing failure, and it is invisible if you count how often the word "price" appears in the JSON: the keys are all present, the values are not.

That is why prices are a separate, opt-in stage. It is one request per product instead of one per sixty, so a priced run is far slower and costs more. Making that a checkbox rather than doing it silently is the point.

Input

FieldTypeRequiredDefaultWhat it does
querystringone of the twolaptopWhat to search for
urlstringone of the twoA Walmart search or category URL. Takes precedence
fetch_pricesbooleannofalseOpen each product's page for price, UPC, brand, seller, category and description
limitintegerno60Products to return, 1 to 600
retriesintegerno3Retry attempts per page

Output

{
"position": 2,
"item_id": "18656507313",
"url": "https://www.walmart.com/ip/HP-14-inch-HD-Windows-Laptop/18656507313",
"title": "HP 14 inch HD Windows Laptop Intel Processor N150 4GB 128GB UFS Waterfall Blue",
"rating": 4.1,
"reviews_count": 805,
"availability": "IN_STOCK",
"sponsored": false,
"price": 259.0,
"was_price": 379.0,
"price_text": "$259.00",
"currency": "USD",
"price_source": "product_page",
"query": "laptop"
}

Use cases

Catalogue and assortment work, cheaply. Leave fetch_prices off and a run is one request per sixty products. You get the full product list with ratings and review counts, which is enough to see what Walmart stocks in a category and which items have traction.

Price monitoring on a shortlist. Turn fetch_prices on for a narrow query rather than a broad one. Fifty tracked products is fifty requests, which is a sensible daily job; five thousand is not.

Finding what people actually buy. reviews_count beside rating separates a 4,8 with eleven reviews from a 4,1 with eight hundred. The second is the one that sells.

Marketplace seller research. seller shows where a listing is Walmart's own and where it is a third party, which is the same question the Amazon buy box answers.

Watching promotions. was_price is only set when there is a real markdown, so a scheduled priced run on a small set is a discount alert.

How it compares

this actor
Per 1.000 products$1,00
Per 1.000 resolved prices$3,00, and only for prices actually found
Needs a browserno
Prices anchored to the right productyes
Sponsored placements flaggedyes

Most published Walmart actors reach the site through a browser or a paid unblocking service, because the plain request returns a bot wall. This one uses a crawler identity that Walmart still serves, which is why it is fast and cheap, and which is also its main risk: single-identity routes close. If it does, the run reports bot_wall and explains it rather than returning nothing.

Pricing

Three events. run_start costs $0,0010 per run. product costs $0,0010 per product written, which is $1,00 per 1.000. product_detail costs $0,0030 and is charged only when a product page was actually read, never for a lookup that came back empty.

Limits and gotchas

  • No prices without fetch_prices. This is Walmart's doing. The run summary says so on every unpriced run rather than leaving an empty column unexplained.
  • The price comes from the product's own object, not from nearby text. An earlier build searched forward from the product id for the closest price block and kept finding the "similar items" rail: it returned $949,99, then $539 on the next run, for a Chromebook that was neither. Reading priceInfo off the object already matched on usItemId cannot pick up a neighbour's price. Prices are now stable run to run.
  • Priced runs are slow. One request per product, deliberately unparallelised. Sixty products takes minutes; six hundred takes a long time. Set the actor timeout accordingly.
  • brand is sparse because Walmart often omits it from the search payload.
  • Sponsored rows are included, flagged with sponsored, because filtering them out silently would misrepresent what the page shows.
  • US only.

FAQ

Why are all my prices and barcodes empty? Because fetch_prices is off. Walmart's search payload has no price, no UPC, usually no brand and no category path. All of it lives on the product page, so it costs one request per product.

Can I get the barcode? Yes, upc, with the detail stage on. It came back on every row in testing.

Why did some products get no price even with fetch_prices on? Because no price block was found close enough to that product's own id on its page. The actor reports that as absent rather than substituting a nearby number that may belong to a different product.

Does it need a proxy or a browser? A residential US exit, yes. A browser, no.

How many products can I get? Up to 600. Without prices that is ten requests; with prices it is 610.