Paste a Zalando product page or a whole category 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 Zalando publishes on its own pages, so the export is exactly as complete as that is.
The input is the page, not the article code - you name the product pages or categories 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.
Point it at a category - including a page-numbered one - and the query column returns that URL character for character, pagination parameter and all. A run assembled from several pages of the same section still reconciles line by line against the list you submitted.
Zalando is one of four retailers the platform names as blocking datacenter IPs or rendering products client-side - Lowes, Grainger and Fastenal are the others. Requests always go out through the proxy pool rather than your own address, but plan for the residential option on this retailer rather than discovering it mid-run.
The brand arrives in its own column rather than glued to the product name, and Zalando's article code arrives in sku. The colourway travels inside the name - AIR JORDAN 1 - Trainers - white/black - so a variant is identifiable even though the export has no colour field of its own.
Each row is one listing as Zalando 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 catalogue - 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, because the price is not the type you would expect.
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.
currency, not in this column.Two things to know before you write code against this. First, price comes back as text with a decimal point and no symbol, so a naive sum concatenates instead of adding, and the unit lives in currency - worth reading per row, because Zalando runs a separate storefront per country. Second, and this governs everything else: the fields are read from the structured data Zalando publishes on its own pages, so the export is exactly as complete as that is. A listing that does not publish a gtin has no gtin to give, and no run setting changes that. 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 single product or a whole category, and the limit is what decides the size and the cost of a run.
A few examples of how teams use marketplace catalogue data to answer a question they actually have.
Run the same section against more than one Zalando storefront and read the price column against the currency column. Because the currency travels per row, a cross-market comparison is a group-by rather than a reconciliation project.
Pull the categories your brand sells into and read what the listings actually say - the wording, the colourways carried, which of your products are surfaced at all. It is the shelf as customers meet it rather than as the range plan describes it.
Feed category URLs instead of individual products and re-run on a schedule. What moves - a price, a new brand appearing in a section, a product dropping out - 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 fashion marketplace, same export shape. Running both across a category is how you see which retailer carries a line and at what price.
A department store rather than a pure-play marketplace, on the same fifteen columns - useful when the question is how a brand travels across very different retail formats.
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 Zalando publishes in the structured data on its own public product pages, for search engines and shopping tools to read. Name, price, 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, a basket 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 wish lists, 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.
Zalando's own terms restrict automated access, so this is a terms question as well as a legal one - if you have a commercial 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 Zalando Products Scraper turns catalogue URLs into a product table. You paste Zalando product or category 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, and this retailer is one the platform flags as needing the residential option.
Each row is one listing: the name, the price and its currency, the availability, the brand, Zalando's own article 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 Zalando publishes on its own pages, which is what keeps the shape stable across a whole category - and also what bounds it, since a field the listing does not publish is not there to collect.
Pricing teams run the same section against more than one country storefront and read price against currency, which travels per row and turns a cross-market comparison into a group-by. Brand and wholesale teams pull the categories their line sells into and read the shelf as customers meet it. 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: the price arrives as text with a decimal point and no symbol, so cast it before you total it, and take the unit from the currency column rather than from the storefront you pointed at. Start free: your first 500 rows cost nothing and need no credit card, and after that it is $0.002 per row, flat.