Point it at a Staples category - office chairs, paper, print supplies, whatever the office is buying - 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 categories, searches 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 categories still reconciles back to your input list.
The input this one is set up for is a category page - everything filed under office chairs, 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 chair or the same toner cartridge 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. Staples 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 Staples 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 Staples, because we hold no populated Staples 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 category on the free tier and look before you build.
A list of URLs and a limit. The input accepts a category, a search 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 office catalogue data to answer a question they actually have.
Pull the categories on your contract - chairs, paper, toner - and put the published prices next to the rates you were quoted. A renewal conversation goes better with the current list price in the same table as the one you are being charged.
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 category 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 other US office-supply catalogue on this same tool, with the same fifteen columns and the same no-proxy setup. Because service is stamped on every row, two retailers can share one table and still be told apart.
Workplace supplies from a European storefront, 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 Staples 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.
Staples' 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 contract 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 Staples Products Scraper turns catalogue URLs into a product table. You paste Staples category, search 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 pull the categories on their supply contract and set the published prices against the rates they were quoted. 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 category 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 Staples because no populated Staples export exists to base them on. Run one category 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.