Give it a Shopify store link - the domain, or a single collection - and get the catalogue back as rows: the product id, title, handle, description, vendor, type, tags, price, sku, availability and the variant itself, plus timestamps and the store's own variant, image and option data. Twenty-two columns, read from the store's public products feed.
The input is the shop, not the product - you name the storefronts or collections you want and the job reads what each one publishes.
One row per variant, each tagged with the query it came from - so a run across several stores still reconciles back to your input list.
This is the thing to know before you count anything. A product with seventeen size and colour combinations produces seventeen rows: the id, title, handle and description repeat, while sku and variant change. Rows are variants - treat them as products and you will overcount a catalogue several times over.
Because the rows are read from the store's public products feed rather than scraped off a page, the export keeps Shopify's own shape: real timestamps, the handle, the vendor and product type, and the full variants, images and options structures carried through as JSON rather than flattened away.
published_at, created_at and updated_at arrive as ISO 8601 timestamps with a UTC offset, which is unusual enough among catalogue exports to be worth saying - no parsing a display format, and a straight sort tells you what a shop added or touched most recently.
Each row is one buyable variant as the store publishes it: what the product is, what this particular size or colour costs, whether it is available, and the structured data Shopify keeps behind it.
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 - three of these columns hold JSON rather than a plain value, and the row you are looking at is a variant rather than a product.
The export's header row, in order, confirmed against the platform's published column list. Where a value shape has actually been observed it is described; where it has not, the entry says what the field is for and stops.
yes or no.Two things to know before you write code against this. First, a row is a variant, not a product: id, title, handle, body_html, url and image repeat down the file while sku and variant change, so group on id when you want products and count rows only when you want variants. Second, variants, images and options each hold JSON inside a single cell - a spreadsheet will show them as a long string, and your parser needs to decode them rather than split on commas. Everything else is plain text, including the price, which carries no currency symbol.
A list of store links and a limit. The only real constraint is that the site has to be built on Shopify - this reads the storefront's own public product feed.
A few examples of how teams use storefront catalogue data to answer a question they actually have.
Because every variant is its own row with its own availability, you can read which sizes or colours a shop has sold through rather than just which products it lists. That is a far better signal about what is selling than a product page ever gives you.
Filter to rows where a was-price is set and you have the shop's entire discount picture in one pass - which lines, which variants, and how deep. Re-run it weekly and the promotional rhythm of a competitor becomes obvious.
Sort by the updated timestamp and the recent activity surfaces itself: new launches, reworked descriptions, quiet price changes. The created and published dates alongside it separate genuinely new products from old ones being refreshed.
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 variants. Worth remembering that a single product can be a dozen rows - the pre-flight estimator shows the row count and credit cost before a run starts.
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 side of the ecosystem - the app store rather than the shops. Useful when the question is which tools merchants are being sold rather than what they sell.
A marketplace rather than an owned storefront. Running both is how you compare a brand's own shop against how it is presented by a retailer.
Short answer: yes for the public catalogue - and this export contains no customer, no order and no inventory data.
Every field here comes from the product feed a Shopify storefront publishes for anyone to read - the same data that populates the shop's own pages and its listings elsewhere. Titles, descriptions, prices, variants and images are public by design. Collecting publicly published catalogue data is long-established practice, and nothing here touches a login, a cart, a checkout or a merchant admin.
There is no personal data in this output at all - it is a product table. No customer names, no orders, no stock quantities, because none of that is in the public feed. The availability column says whether a variant can be bought, which is not the same as how many are left, and this export has no way of knowing the latter.
Shopify's terms and each merchant's own terms may restrict automated access, so this is a terms question as well as a legal one - if you have a relationship with the shop, 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 Shopify Products Scraper turns a store link into a catalogue table. You paste links to Shopify websites one per line - a store domain for the whole shop, or a collection URL for one section - or upload them as a CSV, XLSX, TXT or Parquet file, cap the rows per query, and download the result as a clean CSV, Excel or JSON file.
Each row is one buyable variant: the product id, title, handle and description, the vendor and product type, the tags, the price and any was-price, the sku, whether it is available, and the variant label itself, alongside published, created and updated timestamps and the store's own variants, images and options data. Because the rows come from the storefront's public product feed rather than from a rendered page, the export keeps Shopify's own structure instead of a flattened approximation of it.
Merchandising teams read availability at the variant level to see which sizes and colours a shop has actually sold through. Pricing teams filter to rows carrying a was-price to get a competitor's entire discount picture in one pass. Strategy teams sort on the updated timestamp to see what a shop has been touching, with the created and published dates separating new launches from refreshed listings.
Two practical notes before you plan a job. A row is a variant rather than a product, so a catalogue of a few hundred products can be several thousand rows - group on the product id when you want products. And the variants, images and options columns each hold JSON in a single cell, so decode them rather than splitting on commas. Start free: your first 500 rows cost nothing and need no credit card, and after that it is $0.002 per row, flat.