CDW is a technology reseller, and unlike the other catalogues on this schema you do not have to feed it products one at a time. Give it a category page and it returns a row for every product listed on it - with the price, the CDW part number and the manufacturer part number on each one.
This is the useful difference. Our run submitted a single 2-in-1 laptops category page and got back 24 rows, all reporting ok, all sharing the same query, each with its own product_url. The other catalogue scrapers on this schema give you one row per URL you supply. Here one URL can be a whole shelf, and the published example input for this service is itself a category page.
All 24 rows carried parsed_price, price and currency. Fetch the same product page yourself and you will find both identifiers and the product name in the markup - and no dollar amount anywhere, and no structured-data block either. The price is rendered in the browser. That is exactly why a service that renders the page returns one and a plain HTTP request does not.
sku_code is CDW's own part number - it is also the trailing segment of the product URL and the id inside the image URL. sku is the manufacturer's part number. On our rows those were different values, and both appear on the live page. Check both before choosing a join key: the manufacturer number is what survives a move to a different reseller.
brand, rating, reviews, description and availability were empty on all 24 rows. A reseller listing page carries price and part numbers rather than consumer review furniture, so plan the importer around what arrives rather than around the column list.
Our oldest run carries an eleven-column header - no parsed_price, no sku_code, no product_url, no description, no reviews, no images. Every run from 3 July onward is the seventeen-column form documented below. If you are holding an older CDW export, that is why four of the columns you expect are not there.
Two of our runs came back blocked (needs residential proxy) on the same day that others returned full rows. The status column tells you which is which, so a blocked row is visible rather than silent. Eight runs is far too small a sample to quote a success rate from, so we do not - build in retries.
Read from the header row of a real export, in sheet order. The counts below come from our 24-row run, so where this says a column carried a value it is describing rows we actually hold.
product_url and the id inside the image URL, so the three agree and you can sanity-check a row against itself.parsed_price to do arithmetic.rating.sku_code. This is the column to match on when you are asking whether another reseller lists the same physical product.product_url rather than query - the row points at its own product, not at the shelf it came from.images.ok, blocked (needs residential proxy), no response (proxy) and http 404. Reconcile on this column - especially with a fan-out, where row count alone tells you nothing.Seventeen columns per row · CSV, JSON or Excel
Two things about this table are worth reading before you build against it. First, the prices are real. All 24 rows of our category run carried a number, a formatted price and a currency - this is the one catalogue in this family whose money columns arrive populated. But fetching the same product page directly returns about 57 KB of HTML that contains both part numbers and the product name and no price at all, with no structured-data block to read one from. The figure is rendered in the browser. Our export has it because the service renders the page, and a scraper built on an HTTP library and an HTML parser would come back empty-handed while appearing to work. Second, the schema moved. Our 1 July run carries an eleven-column header - query, name, brand, price, currency, sku, availability, rating, url, image, status - with no parsed_price, sku_code, product_url, description, reviews or images. Everything from 3 July onward is the seventeen-column form above. If you are reconciling against an older export, that is the difference.
Submit the category pages you care about rather than enumerating products. One URL returned two dozen priced rows in our run, so a weekly sweep of a handful of categories is a small job that produces a real price series. This is the workflow the service is shaped for.
sku is the manufacturer's part number, so it survives the move from CDW to a competitor's catalogue where CDW's own sku_code does not. Pair it with parsed_price and you can answer who is cheaper on an identical part rather than on a similar-sounding name.
Reseller listings put the configuration in the title - processor, memory, storage. With description empty, name is where that detail lives, and parsing it gives you a comparable spec table across a category without opening a single page.
sku_code is the number CDW uses on its own system, which makes it the one to reconcile quotes and invoices against. Keep both identifier columns and you can speak to the reseller in their numbering and to your asset register in the manufacturer's.
One time, on signup. No card, and nothing to cancel afterwards.
Billed on rows actually returned - which matters here more than elsewhere, because one category URL can produce dozens of rows. Our 24-row run cost 24 rows, not one.
Credits do not expire on a monthly cycle. Run a category sweep in March and nothing until September if that is the shape of the work.
LIVESCRAPER10 at checkout.The same schema aimed at the consumer side of the same hardware market - the obvious second source when you are comparing a business price against a retail one.
Another distributor whose two identifier columns hold different numbers. There the price sits behind a login; here it arrives.
Another catalogue that renders client side, on the same schema - useful if you are building one importer for several sources.
A dated image of the listing beside the row. Worth having when a price is evidence: the figure is not in the page source, so the render is the only record of it.
Prices and part numbers on a publicly reachable listing are ordinary competitive information. The caveats worth naming here are about rate and about reading the site's own stated preferences.
A price, a product name and a part number are facts about goods offered for sale. Reading them from a page served to any visitor is the same activity a buyer performs by hand, at a useful speed. Nothing in the seventeen columns describes a person: no name, no email address, no phone number, no account - so the data-protection questions that shape our people-facing services do not arise here.
Two things are specific to this site. First, rate. A category URL that fans out into two dozen rows is doing more work per request than a single product fetch, and two of our own runs came back blocked on a day when others succeeded. We run at a considerate pace and we surface a block in the status column rather than retrying it into the ground; you should schedule accordingly rather than treating a fan-out as a free multiplier. Second, the site's stated preferences. CDW's robots.txt returns 403 to a plain client and 200 to a browser user-agent - we report that rather than pretending the file read cleanly. Read with a browser user-agent it carries no blanket exclusion for general crawlers, and neither the product path nor the category path we used is disallowed.
Our own terms are the same as on every other service here. Publicly available pages only, nothing behind a login, no third-party trackers on the data layer, and exports auto-delete after 30 days. Your first 500 rows are free and need no credit card.
ok, all sharing the same query, each with its own product_url. The published example input for this service is itself a category page. A product URL works too and returns a single row.parsed_price, price and currency. That makes CDW unusual among the catalogues on this schema, where the money columns are often empty for reasons particular to each site.query, sku_code, product_url, name, parsed_price, price, currency, images, sku, url, image and status. Empty on all 24: description, availability, rating, reviews and brand.sku_code is CDW's own part number - the same value that ends the product URL and appears inside the image URL - and sku is the manufacturer's. Use CDW's number to talk to CDW about a quote, and the manufacturer's to find the same physical product in another reseller's catalogue.parsed_price, sku_code, product_url, description, reviews or images. Every run from 3 July onward is the seventeen-column form. If you are reconciling old against new, that is the difference.ok, blocked (needs residential proxy), no response (proxy) and http 404 - the last on a placeholder address that does not exist. Reconcile on this column rather than on row count, which a fan-out makes meaningless on its own.One category URL, a row for every product on it, with the price and both part numbers on each. Your first 500 rows are free, then $0.002 each.
CDW is a technology reseller selling hardware, software and services to businesses, government and education. Two things make scraping it different from the other catalogues that share this seventeen-column schema, and both are worth knowing before you write an importer. The first is that a category URL fans out. Our run submitted a single 2-in-1 laptops category page and received twenty-four rows, every one reporting success, every one sharing the submitted URL in query and carrying its own distinct product_url. Everywhere else in this family one URL means one row. Here one URL can be an entire shelf, and the vendor's own published example input for this service is a category page rather than a product page - the fan-out is the intended workflow, not a side effect.
The second is the price. All twenty-four rows carried a computable number, a formatted price and a currency, which makes CDW unusual here: on our other catalogue pages the money columns are empty for reasons particular to each site. What makes it interesting is where that price is not. Fetching the same product page directly returns roughly 57 KB of HTML that contains CDW's part number, the manufacturer's part number and the full product name - and no dollar amount at all, with no structured-data block to read one from. The figure is rendered in the browser after the markup arrives. A scraper built on an HTTP library and an HTML parser will find the identifiers, miss the price entirely, and give every appearance of working. This service loads the page the way a browser does, which is the whole reason the column is populated.
The identifier columns repay attention. sku_code is CDW's own part number, and it is also the trailing segment of the product URL and the id embedded in the image URL, so a row can be sanity-checked against itself. sku is the manufacturer's part number and a genuinely different value. The manufacturer's number is what survives a move to a different reseller, so it is the column to match on when you are asking whether someone else lists the same physical hardware; CDW's is the one that reconciles against a quote. Five columns did come back empty on every row - brand, rating, reviews, description and availability - which is what a business listing looks like: part numbers and price rather than consumer review furniture. The manufacturer is usually the first word of name if you need to group by it.
Two caveats stated rather than buried. The schema changed between 1 and 3 July 2026: our oldest run carries an eleven-column header with no parsed_price, sku_code, product_url, description, reviews or images, and everything after it is the seventeen-column form. If you hold an older export, that is why the columns do not line up. And blocking is real and intermittent - two of our eight runs returned blocked (needs residential proxy) on the same day that others returned full rows, so the status column matters and a schedule should include retries. Eight runs is far too small a sample to quote a success rate from and we do not quote one. On access: CDW's robots.txt returns 403 to a plain client and 200 to a browser user-agent, which we report rather than glossing; read that way it carries no blanket exclusion, and neither the product nor the category path we used is disallowed. Publicly available pages only, no third-party trackers on the data layer, and exports auto-delete after 30 days. Your first 500 rows are free and need no credit card.