This is the only service in our catalogue whose price column is a ladder. One promotional-products URL came back with twenty-one of twenty-three columns filled, and the pricing field holds five quantity breaks where every other page here holds a single figure. We checked the row against the live page, and against the supplier page it points at.
ProductDetails pages on the storefront this service reads.pricing on our row held five quantity breaks in one string, and the unit price falls as the quantity rises. price_from is not the price at the smallest quantity - it is the cheapest rung, the one you only reach at the largest order. Treat it as a floor, not a starting point, or every quote you build from this file will be too low.
This is the trap. You submit a WB Mason storefront address, and the url column comes back pointing at a different company's website - the supplier that actually makes the item. We confirmed the supplier is named on the WB Mason page, so it is not a mix-up. But an importer that assumes url is a link back to the site you queried will build a catalogue full of outbound links to somebody else.
This is not a retail schema with an imprint field bolted on. imprint_methods, imprint_colors, imprint_sizes, full_color_process, personalization and sold_unimprinted are all separate columns. On our row the first three carried real values - a list of methods, fifteen named colours and three imprint areas - while the last three tell you what the item does not support. That is the shape of promotional-products data, and it is why the column list here is longer than on our retail pages.
shipping_weight did not come back as a weight. It came back as a stringified object - the internal structure printed rather than read - carrying two nested descriptions and a trailing unit word. It is not valid JSON, because the quotes are the wrong kind, so a parser will refuse it. There is a usable weight inside it, but you will be extracting it with a regular expression rather than a field access. We are flagging this rather than quietly tidying it, because the export is what you will actually receive.
image held a relative path rather than a fetchable URL - a directory segment and an identifier, with no scheme and no host. Every other catalogue service we run returns an absolute image address, so this one needs a base prepended before anything will load. Worth catching in your loader rather than in your CDN logs.
The page you submit returns about 290 KB of HTML and carries no structured-data block at all - it is a client-rendered application, so every value had to be read from the rendered page rather than lifted from a machine-readable record. We still corroborated the row: the item number, the product name, the top and bottom rungs of the price ladder, the country of origin and the material all appear on it, and the material's unusual capitalisation on our row turns out to be exactly how the page writes it. The supplier page named in url carries the same item number and the same floor price.
Read from a real export, in sheet order. The notes come from one product our runs returned three times and from direct fetches of both the page we submitted and the supplier page it points at. Where this says a column carried a value, it is describing a row we actually hold.
sizes; see the note below.pricing, the one that applies only at the largest quantity. It is a floor, not a starting price.ok on the real storefront URL and http 404 on the two placeholder submissions, which is what a fictional address returns. Read it first.Twenty-three columns per row · CSV, JSON or Excel
Read this table with one number in mind: one. Our five runs produced three successful rows and those three rows are byte-identical - the same product, fetched three times over two days. So everything above describes one item well and says nothing about how the service behaves across a catalogue. Twenty-one of the twenty-three columns carried values on it, and we corroborated them against two live pages, but we cannot tell you whether the next product fills the same columns. Four things will bite an importer, and all four are properties of the export rather than of that item. price_from is the cheapest rung of the quantity ladder, not the entry price. url points at the supplier's own site, not at WB Mason. image is a relative path and needs a base. And shipping_weight is a stringified object that no JSON parser will accept. One more thing we will report but not resolve: the size in name and the number in sizes do not agree, and the weight blob mentions two different sizes as well. We do not know which is the product dimension, so we are not going to guess on your behalf.
The ladder is the point. Split pricing into quantity and unit price and you can compute a line total at any break without asking anyone - and you can see the gap between the entry rung and the floor, which is what price_from alone hides.
Imprint method, colours and printable areas are separate columns, so a shortlist of items that accept a particular decoration is a filter rather than a reading exercise. sold_unimprinted is a real boolean, which makes the blank-stock question a one-line query.
production_time and origin arrive together, which is the pair that decides whether an item can land in time. Both are free text on our row, so plan on parsing the range before you sort on it.
Because url resolves to the supplier's own site rather than the storefront, a run over a shortlist tells you which manufacturer sits behind each listing. That is unusual, and once you know the column behaves that way it stops being a bug and starts being useful.
One time, on signup. No card, and nothing to cancel afterwards.
Billed on rows actually returned. This service returned one row per submitted URL on every run we hold, so a list of URLs costs about what the list length suggests.
Credits do not expire on a monthly cycle. Price a promotional range once a quarter and nothing in between if that is the shape of the work.
LIVESCRAPER10 at checkout.The other customisation-led catalogue we cover - worth reading beside this one if you are comparing how two print businesses expose their options.
A packaging catalogue on our standard seventeen columns, where one category URL returned 99 priced rows. The contrast with the ladder here is the point.
The fullest row we hold on the standard schema - fifteen of seventeen columns, every value confirmed against the live listing.
A dated image of the listing beside the row, for when a quoted price needs to be evidence rather than a number in a file.
Catalogue prices and item numbers on a public storefront are ordinary commercial facts. Access here was the least eventful of any site we cover, and the caveats are about the data rather than about permission.
A price, a product name and a catalogue number are facts about goods offered for sale, read from a page served to any visitor. Nothing in the twenty-three 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 prices are published on the listing rather than behind an account, which is why the money columns in this export arrive full.
Access was the simplest we have recorded. The storefront's robots.txt answered a plain request with HTTP 200 on 12 August 2026 and is ninety bytes long: one general group, a single disallowed path that has nothing to do with products, and a sitemap line. Read with a proper group matcher, the product-detail path this service uses is allowed. Nothing we ran was blocked, and the only unsuccessful rows in our export are the service returning a not-found for a placeholder address that does not exist. One honest caveat about scope rather than permission: the page is a client-rendered application with no structured data, so the values are read from the rendered page - which is more fragile to a redesign than a machine-readable record would be.
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.
pricing column held five quantity breaks on our row, with the unit price falling at each step. price_from is the cheapest of those rungs - the one you reach only at the largest quantity - so treating it as the price of one unit will understate every quote you build.url links back to WB Mason will be wrong on every row.full_color_process and personalization were empty, and on that item both look like an absence of the option rather than missing data - though one product cannot settle that.url carries the same item number and the same floor price.sizes column holds roughly double it, and the shipping-weight blob mentions two different sizes as well. It may be inflated against flat, or diameter against circumference. Check it on the listing before you rely on either.sold_unimprinted is a real boolean in the JSON, which is worth remembering if you round-trip through a format that has no boolean type.Twenty-three columns including five quantity breaks, six decoration fields and a supplier link, from one storefront URL - with every value confirmed against two live pages. Your first 500 rows are free, then $0.002 each.
WB Mason is best known as an office-supply distributor, but the storefront this service reads is its promotional-products catalogue - branded merchandise ordered in bulk and printed to order. That distinction shapes everything about the export. Instead of the seventeen retail columns our other catalogue services return, this one returns twenty-three, and six of them are about decoration: which imprint methods the item accepts, which colours, which printable areas, whether it supports full-colour process printing, whether it can be personalised, and whether it can be bought undecorated at all. A reader arriving here expecting copier paper will find something quite different, and the page is written for the buyer who actually wants this data.
The single most important difference is the price. Every other catalogue page on this site reports one number per product; this one reports a ladder. Our run returned five quantity breaks in a single field, with the unit price falling at each step as the order grows. That makes the accompanying column a trap worth naming plainly: the value labelled as the price the item starts from is in fact the cheapest rung, the rate you reach only at the largest quantity. It is a floor, not an entry price, and a quote built from it without reading the ladder will come out low every time. Splitting that field takes two delimiters - one between breaks and one between quantity and rate - and it is the first thing to write in an importer.
Three further properties of the file will catch a loader written against our other services. The address column does not point at WB Mason: it resolves to the supplier who manufactures the item, on that company's own domain. We verified the supplier is named on the storefront page, so this is deliberate rather than a mix-up, and it is genuinely useful for supply mapping once you expect it. The image column holds a relative path rather than a fetchable address, so it needs a base prepended. And the shipping-weight column holds a stringified object rather than a number, quoted in a style no JSON parser will accept, with two nested descriptions and a unit word trailing after the closing brace. There is a real weight in there; getting it out is a regular expression, not a field access.
We checked the row rather than trusting it. On 12 August 2026 the storefront page answered a plain request with about two hundred and ninety kilobytes of HTML, and it carries no structured-data block at all - it is a client-rendered application, so every value in the export had to come from the rendered page. Even so the item number, the product name, the top and bottom rungs of the ladder, the country of origin and the material all appear on it, and the material's unusual capitalisation in our row turns out to be exactly how the page writes it. The supplier page named in the address column carries the same item number and the same floor price. What we cannot offer is breadth: our five runs produced three successful rows and those three are byte-identical, so they are one product observed three times rather than three products. The remaining two submitted a placeholder address and returned a not-found. That is a well-corroborated single row and an untested catalogue, and we would rather label it that way than let the row count read as coverage. Access itself was the least eventful of any site we cover - the storefront's robots.txt is ninety bytes long and allows the product path. Publicly available pages only, no third-party trackers on the data layer, exports auto-delete after 30 days, and your first 500 rows are free with no credit card.