The Zara Scraper API returns raw page HTML for Zara URLs you supply

What the service actually returns

The Zara Scraper is part of the Oxylabs Web Scraper API, described as a real-time data gathering solution that combines automated proxy management, web data access and parsing to collect structured data from any public website at scale. The important qualification is in the guide itself, in the section explaining how it works. You get Zara results by providing your own URLs to the service, and it can return the HTML for any Zara page you like.

So the mechanism is a render-and-return endpoint, not a product database. You do not query by SKU, category or price range. You hand over a Zara page URL, and the service fetches that page and gives you back its HTML as JSON. The extraction of product details, price and availability, which the repository description lists as the point of the tool, is something you do on top of the returned page source.

That distinction is the single most important thing to understand before adopting it. If you want a structured feed of the Zara catalogue with typed fields, this is a page fetcher and you write the parsing. If you want to fetch a specific product page or category listing on demand and then parse it yourself, that is exactly what this is for.

The guide states its own use case plainly: gathering data exclusive to Zara web pages, taking hold of fashion detail including clothing prices, user reviews and garment descriptions, to evaluate the fashion market and stay on top of competition. That is a market intelligence framing, and it explains why the unit of work is a URL rather than a search query.

The request shape and the response envelope

The documented example is a single POST to a queries endpoint with a JSON payload, and it is short enough to read as the whole API surface:

import requests
from pprint import pprint

# Structure payload.
payload = {
    'source': 'universal',
    'url': 'https://www.zara.com/ww/en/woman-blazers-l1055.html?v1=2290737'
}

# Get response.
response = requests.request(
    'POST',
    'https://realtime.oxylabs.io/v1/queries',
    auth=('user', 'pass1'),
    json=payload,
)

Two fields carry the work. The source is set to universal, which tells the service which upstream to use, and the url is the Zara page you want. Authentication is HTTP basic with a username and password pair, and the credentials are placeholders in the documentation, which is a reminder that your own account credentials go there.

The response envelope is worth reading carefully because it contains a field that does not appear in the request. The results array holds one object per fetched page, and inside it sit the content field with the HTML, a created_at and updated_at pair with timestamps, a page number, the url that was fetched, a job_id, and a status_code. The comment in the example explains the design: rather than returning a response with job status and a results URL, this call returns the JSON response with the result directly. That is a synchronous mode, and the job_id is still present in the payload, which suggests the same envelope carries the identifiers an asynchronous flow would need.

The status_code field is the one to build error handling around. It reports the upstream response code for the page, so a page that Zara serves with a non-200 status comes back with a 200 API response and a status_code telling you what actually happened. The content field is also truncated in the documentation example, which shows an ellipsis mid-document, so do not assume the example tells you how much HTML you receive in full.

Getting code for other languages

The repository is almost entirely documentation. The top level holds a README.md and a single code examples directory, and the guide points readers to that directory for examples in other programming languages, hosted on the code examples branch path of the repository. Java is listed as the primary language, which is a reasonable signal that the largest set of examples is Java, and the Python example above is the one shown inline in the guide.

There is no build file, no package manifest, no test suite and no source tree to clone and run. That is the defining fact about this repository. It is documentation and example snippets for a hosted commercial service, and it is not archived, with the last push recorded on 2026-06-08. There are no GitHub releases either, which is consistent with a documentation repository that tracks the service rather than shipping an artefact.

So the way to use this project is to read the guide, copy the example for your language, and point it at the endpoint with your own credentials. Support is offered through live chat and a support email address given in the guide. The licence field is not stated in a form the repository can classify, so if you plan to do anything with the example code beyond calling the service, that is a question for Oxylabs rather than something the repository answers.

Why a hosted endpoint instead of scraping Zara yourself

The alternative is to fetch Zara pages yourself with an HTTP client or a headless browser, and the difference in approach is about who absorbs the hard parts. Doing it yourself means handling whatever Zara serves to your IP, which changes as their defences change, and you maintain the requests, the parsing and the retries. The service route moves that work behind the endpoint and gives you a stable JSON contract with a status_code and a job identifier.

The gap between the two approaches widens as your volume and your selectivity grow. A single page fetch from a residential connection is a two-line requests call, and a hosted endpoint adds little. A few thousand pages across many categories is where self-hosted scraping starts to consume engineer time in anti-bot handling, and where a vendor that sells proxies for a living has a genuine advantage, since proxy management is listed as one of the three things the service combines.

There is a middle path worth considering before either. A general purpose scraping framework with browser automation, proxy rotation and a scheduler of your own gives you the same control with the maintenance burden visible to you rather than billed per query. You pay for infrastructure and your own time instead of per request, and you can point the same code at other retailers. The hosted endpoint wins when the goal is one specific site, the volume is steady and the team would rather not maintain collection infrastructure at all.

Where this approach is the wrong one

The first limitation is the one the guide itself hints at. You get HTML, not fields. If what you need is a reliable numeric price for ten thousand products, the parsing, the currency handling, the variant logic and the handling of missing values are all yours, and a change to Zara's page markup breaks them without warning. A service that returns typed product fields absorbs that work, and this one does not, so judge it against the cost of your own parser rather than against a competing extractor.

The second is the commercial dependency. The endpoint is a hosted service with credentials, so your pipeline now depends on an external provider being reachable, and on its pricing. There is no offline mode and no self-hosted variant in this repository. If a procurement conversation is part of your work, note that the licence is not stated in a form the repository can classify, which means you will be relying on Oxylabs' terms rather than an open source grant.

The third is legal and operational, and it applies to the whole category. Zara's terms govern automated access to its site, and the service does not change that. The repository frames the use as market evaluation and competitor analysis, which is a normal commercial activity, but running a large collection job against a site whose terms prohibit it, or against accounts you do not control, is a different thing and carries legal exposure that no API convenience removes. The same goes for the data you collect: a price and a description are different in kind from a review text or anything involving a person, and the further you go from catalogue fields into content, the more your obligations change.

There is also a scale dependency. If your need is a one-off check of a few dozen pages, a browser extension or a manual copy is faster and free, and this service is overkill. The hosted endpoint earns its cost when collection is continuous and volume is high enough that failures and blocks become your daily problem.

Editorial conclusion

Adopt the Zara Scraper API if you need Zara pages as structured input, you would rather not run your own proxy pool and browser fleet, and you are comfortable sending your requests through a hosted Oxylabs service with an account and credentials. Do not adopt it if you need a free self-hosted option, since the endpoint is commercial and the repository holds documentation rather than code you can run yourself. Before you commit, confirm the target URLs return the fields you need in the HTML the service hands back, since the API returns page source rather than parsed product fields, and check the terms for the target site before automating against it.

Frequently asked questions

Official sources

1. Issues
2. oxylabs/zara-scraper on GitHub
3. README