Waxie is a sanitary-supply wholesaler, so its item pages carry what a purchasing system needs - a product name, a description, the distributor's item number and the manufacturer's - and show a price only to a signed-in account. This service returns the seventeen columns. The identity fields come back; the money fields do not, and we say which before you sign up.
This is the useful thing about a distributor. On our real row sku_code was 1033704 - Waxie's own item number - and sku was 80009, which the page labels in as many words as Manufacturer Item. Both are on the live page and both are in the export. Every page in this family tells you to check both before choosing a join key; here is the case that shows why.
price, parsed_price, currency and availability were empty on both of our real rows. Fetch the item page yourself and you will see why: an anonymous visitor gets the product and a sign-in prompt, not a figure. Waxie's published service note says the same - a wholesale site where some data cannot be read without a login. We do not log in, so we do not have it.
The item URLs carry a warehouse-id. That is a wholesaler quoting against a particular branch's stock and a particular account's terms, which is a second reason there is no single public number to read - even the signed-in figure is specific to who is asking and from where.
Our two successful runs submitted the same item five minutes apart and both returned status: ok. The first came back with the product name and nothing else; the second added the description, both identifiers and the canonical URL. Same page, same day, different depth - so treat a thin row as something to retry rather than as proof the field is absent.
The live item page names its manufacturer, and our brand column was empty on both real rows anyway. We are recording that as a gap rather than explaining it away. If you need the manufacturer, the description text is where it tends to appear.
The last column is status, written by our exporter rather than by the site. Across our four runs it took two values - ok and http 404, the latter on a placeholder address that does not exist - so a row that failed still arrives carrying the reason.
Read from the header row of a real export, in sheet order. Where we observed a column carry a value, this says what the value looked like. Where we observed it empty on every row, it says that instead.
url exactly.1033704 on our real row, the number the item page leads with. This is the one to use when you are talking to Waxie about an order.WAXIE MULTI-TASK WIPES BUCKETS on our row. Expect distributor shorthand in capitals rather than marketing prose.rating.description if you need it.80009 on our real row, and labelled as such on the page. Different from sku_code above, and the one to use when you are matching the same physical product across two different distributors.query on every row we hold, which tells you these requests were served without redirecting.ok and http 404. Reconcile on this column rather than on row count.Seventeen columns per row · CSV, JSON or Excel
Why the money columns are empty, stated plainly. We hold four runs of this service. Two submitted a real Waxie item and returned status: ok; two submitted a placeholder address that does not exist and returned http 404. On both real rows, price, parsed_price, currency and availability were empty strings - and so were rating, reviews, brand, image and images. That is a property of the source rather than a defect here: fetching the item page directly returns a working page of about 131 KB that shows the product, both item numbers and a sign-in prompt, and no price to anyone who is not logged in. Waxie's own published service note describes it as a wholesale site where some data cannot be read without a login, which is the same fact from the other direction. One more caveat worth your attention: our two successful runs were the same URL five minutes apart, and the earlier one returned only the product name while the later one returned the description, both identifiers and the canonical URL. Same page, same day, different depth. Retry a thin row before concluding a field is empty.
sku is the manufacturer's number, so it survives the move from one distributor to another where sku_code does not. That is the join key for asking whether the item you buy from Waxie is the item a competitor lists - a question a name match will not answer reliably on capitalised trade descriptions.
sku_code is the number Waxie uses on its own system, which makes it the one to reconcile purchase orders and invoices against. Keep both columns and you can talk to the distributor in their numbering and to your own database in the manufacturer's.
On a wholesale catalogue the pack breakdown is frequently written into the product text rather than exposed as a field, and our row was no exception. description is where to parse it from if your system needs a case quantity beside the item.
Run a set of item URLs on a schedule and keep name, description and both identifiers with the run date. You will not get price movement from this, but you will see products renamed, re-described or withdrawn, which a wholesaler rarely announces.
One time, on signup. No card, and nothing to cancel afterwards.
Billed on rows actually returned. A row that comes back with a status other than a successful one is not a row of product data, and is not charged as one.
Credits do not expire on a monthly cycle. Run a catalogue sweep in March and nothing until September if that is the shape of the work.
LIVESCRAPER10 at checkout.Another distributor catalogue on the same schema. That one renders in JavaScript; this one does not, which is the sort of difference that decides how a scrape is built.
The same seventeen columns with the identifier fields carrying one value rather than two - a useful contrast when deciding which column to join on.
The same schema pointed at a consumer retailer instead of a wholesaler, where the price columns have something public to carry.
A dated picture of the item page beside the row. Worth having when the page shows a sign-in prompt where a price would be.
Product facts on a publicly reachable page are ordinary competitive information. The caveats worth naming here are about the sign-in boundary and about a site that publishes no robots file.
A product name, a description and an item 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.
The boundary that matters on this site is the sign-in. Waxie is a wholesaler, and pricing, branch stock and account terms sit behind its Web@Work login - the service's own published note says as much. We do not log in, we do not use anyone's credentials and we do not work around the prompt, so what this service reaches is what an anonymous visitor reaches. That is a real limit rather than a temporary one: if the figure you need only appears once you are signed in as a particular account, nothing here will produce it. Worth being straight about the second point too - shop.waxie.com serves no robots.txt at all, it returns 404. We read that as the absence of an instruction rather than as permission, which is why this service stays on the same footing it uses everywhere else: public pages, anonymous, at a considerate rate.
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.
price, parsed_price, currency and availability were empty on both of our real rows. Waxie is a wholesale site and shows pricing only to a signed-in Web@Work account - its own published service note says some data cannot be read without a login. We do not log in and do not use anyone's credentials, so this service sees what an anonymous visitor sees. No setting will change that.sku_code is Waxie's own item number - 1033704 on our row - and sku is the manufacturer's, 80009, which the page labels as the manufacturer item. Use sku_code to talk to Waxie about an order, and sku to match the same physical product in someone else's catalogue.query, sku_code, product_url, name, description, sku, url and status. Empty on every row we hold: parsed_price, price, currency, availability, rating, reviews, images, brand and image.ok; the earlier returned the product name alone and the later added the description, both identifiers and the canonical URL. The practical advice is to retry a thin row before concluding a field is empty for that product.query, sku_code, product_url, name, description, parsed_price, price, currency, availability, rating, reviews, images, brand, sku, url, image and status. One row per item URL you submit.description, so that is where to parse it from.ok on the two real item requests and http 404 on two runs that submitted a placeholder address which does not exist. A failed row still arrives carrying its reason.Name, description and both item numbers for every Waxie URL you submit - and an honest empty cell where the price sits behind a sign-in. Your first 500 rows are free, then $0.002 each.
Waxie is a sanitary-supply and janitorial wholesaler selling to trade accounts rather than to consumers, and that shapes what an item page can tell you. The useful fields are the ones a purchasing system needs - a product name, a description carrying the pack breakdown, and two separate item numbers - while price, branch stock and account terms sit behind the Web@Work sign-in. The service's own published note puts it plainly: a B2B wholesale site where some data cannot be read without a login.
The two identifier columns are the reason this export is worth having. On the real row we hold, sku_code was 1033704 - Waxie's own item number, the one the page leads with and the one to quote on an order - and sku was 80009, which the page labels in as many words as the manufacturer's item number. Both values appear in the live page, which is how we know the row is genuine rather than a parsing accident. Every scraper in this family advises checking both identifier fields before you choose a join key; Waxie is the case that shows why it matters. The manufacturer's number is what survives a move from one distributor to another, so it is the column to match on when you are asking whether two catalogues list the same physical product. The distributor's number is what reconciles against purchase orders.
What does not come back is money. price, parsed_price, currency and availability were empty on both of our real rows, and so were rating, reviews, brand, image and images. Fetching the item page directly explains the first group: it returns a working page of roughly 131 KB showing the product, both item numbers and a sign-in prompt, with no figure anywhere for a visitor who is not logged in. The item URLs also carry a warehouse identifier, so even the signed-in price is scoped to a branch and an account - there is no single public number for anyone to read. The empty brand is a genuine gap rather than a property of the source, because the live page does print a manufacturer, and we record it as such.
One consistency caveat deserves stating rather than burying. Our two successful runs submitted the same item URL five minutes apart and both reported success, but the earlier returned only the product name while the later added the description, both identifiers and the canonical URL. Same page, same day, different depth. Retry a thin row before you conclude a field is absent for that product. Two runs is also far too small a sample to quote a success rate from, so we do not quote one. Note finally that shop.waxie.com publishes no robots.txt - the request returns 404 - which we treat as the absence of an instruction rather than as permission: publicly available pages only, anonymous, at a considerate rate, 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.