Search WebstaurantStore for a category - chef knives, prep tables, anything a commercial kitchen buys - or paste a product page, and get the listings back as rows: name, price, currency, availability, brand, sku, mpn, gtin, rating, reviews, image, link and description. The fields are read from the structured data the pages publish.
The input is the page, not the item number - you name the searches, categories or products you want, and the job reads what each listing publishes.
One row per product, each tagged with the query it came from - so a run across a dozen searches still reconciles back to your input list.
The input this catalogue is built for is a search or category page - everything the store lists for chef knife, say - rather than a URL you already had to find. One line becomes a shortlist, and the limit per query decides how much of it you take.
Alongside the retailer's own stock code the export carries mpn and gtin where the listing publishes them - the fields that let the same pan or the same slicer be matched across suppliers who each file it under a different number of their own.
Every request goes out through the shared proxy pool rather than your own address. WebstaurantStore is not one of the retailers the platform flags as needing a residential connection - Lowes, Grainger, Zalando and Fastenal are - so the default pool is what this one runs on.
Each row is one listing as WebstaurantStore publishes it: what it is called, what it costs, who makes it, how it is identified and what the page says about it.
The fields come from the structured data on the page rather than from scraping the layout, which is what makes the shape stable across a whole search result - and also what bounds it. A field the retailer does not publish does not appear, no matter how the run is configured. The column list below is the header row of real run exports and the platform's own published list, which agree exactly; read the note under it before you write a parser.
The export's header row, in order, confirmed against the platform's published column list. Descriptions say what each field is for; they claim nothing about its format or how often it arrives filled - see the note underneath.
currency, not in this column.Read this dictionary as a list of names, not a promise about contents. The fifteen names and their order are solid - the published column list and the header row of every archived run of this scraper agree exactly. What is not settled is what arrives in them for WebstaurantStore, because we hold no populated WebstaurantStore export: the runs we have are either empty or from a different retailer on the same shared tool, and one retailer's structured data tells you nothing reliable about another's. That is also why the mechanism matters more here than a format would: the fields are read from the structured data the listings publish, so the export is exactly as complete as that is. query and service are the exceptions - the scraper writes those itself, so they are on every row regardless. If gtin or mpn is load-bearing for your work, run one search on the free tier and look before you build.
A list of URLs and a limit. The input accepts a search, a category or a single product, and the limit is what decides the size and the cost of a run.
A few examples of how teams use foodservice catalogue data to answer a question they actually have.
Search each category you are buying - ranges, prep tables, smallwares - and put the published prices next to the quote on your desk. A spec list becomes a comparison instead of a leap of faith, and the gaps are the conversation to have with the supplier.
Export a category and join on mpn or gtin rather than on the stock code, which every distributor assigns differently. That is what turns several supplier catalogues into one comparable list instead of several spreadsheets nobody can reconcile.
Feed search URLs instead of individual products and re-run on a schedule. What moves - a price, a stock status, a new brand appearing in a result set - is visible as a diff between two exports rather than as something somebody had to notice.
No subscription, no minimum, no recurring bill. Your first 500 rows are on us - after that, pay-as-you-go at the same flat rate as every other scraper here.
Every new account, one-time. No credit card required. Per-query limits, file upload and every export format included.
Roughly $2 per 1,000 products. The pre-flight estimator shows the row count and credit cost before a run starts - no surprise bills, no compute units to translate.
Volume pricing, dedicated workers and an SLA for continuous monitoring or very large catalogue pulls. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.The MRO distributor on this same tool, with the same fifteen columns. Worth knowing that unlike this one, Grainger is flagged as needing a residential connection.
Workplace supplies rather than commercial kitchen, same shared tool and same export shape - and like this one, it needs no residential connection.
Short answer: yes for the public catalogue - and this export contains no account, no customer and no order data.
The fields collected here are the ones WebstaurantStore publishes in the structured data on its own public product pages, for search engines and shopping tools to read. Name, price, availability, brand and identifiers are shown to anyone who opens the page, signed in or not. Collecting publicly published catalogue data is long-established practice, and nothing here touches a login, an account or a checkout.
There is no personal data in this output at all - it is a product table. No customer names, no order history, no negotiated pricing, because none of that is public. Whatever your account sees when signed in is not what this reads, and that is a deliberate boundary rather than a limitation to work around.
WebstaurantStore's own terms restrict automated access, so this is a terms question as well as a legal one - if you have an account or a supply relationship with them, check it. We run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
500 one-time free rows on every new account - no expiry. After that it is $0.002 per row, pay-as-you-go - no card on file until you say so.
Livescraper's WebstaurantStore Products Scraper turns catalogue URLs into a product table. You paste WebstaurantStore search, category or product URLs one per line - or upload them as a CSV, XLSX, TXT or Parquet file - cap the rows per query, and download the results as a clean CSV, Excel or JSON file. Requests go out through the shared proxy pool rather than your own address.
Each row is one listing: the name, the price and its currency, the availability, the brand, the retailer's own stock code, the manufacturer part number, the gtin, the rating and review count, the image, the product link and the description. Those fields are read from the structured data the listings publish, which is what keeps the shape stable across a whole set of search results - and also what bounds it, since a field a listing does not publish is not there to collect.
Procurement teams search each category they are buying and set the published prices against the quote on the desk. Data teams export a category and join on mpn or gtin rather than the stock code, which every distributor assigns differently, turning several supplier catalogues into one comparable list. Strategy teams feed search URLs on a schedule and read what moved between two exports instead of relying on somebody noticing.
One practical note up front: this page describes the fifteen columns and their order, which the archived exports and the platform's published list agree on exactly, but it claims no formats or fill rates for WebstaurantStore because no populated WebstaurantStore export exists to base them on. Run one search on the free tier and look at the first rows before you build against it. Your first 500 rows cost nothing and need no credit card, and after that it is $0.002 per row, flat.