Lazada Scraper API: fetching Lazada pages through a hosted universal endpoint

The request is a source and a URL, and the response is HTML

Lazada Scraper is described as a data gathering solution that allows you to extract real-time information from a Lazada website, and it is part of the vendor's Web Scraper API product. The README calls it a brief guide and says it explains how the scraper works with code examples.

The mechanism is one endpoint. You provide your own URLs to the service, and it returns the HTML for any Lazada page you like. The Python example in the README shows the whole thing:

import requests
from pprint import pprint

# Structure payload.
payload = {
    'source': 'universal',
    'url': 'https://www.lazada.com.ph/'
}

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

# Instead of response with job status and results url, this will return the
# JSON response with the result.
pprint(response.json())

The source value of universal tells the service which of its fetchers to use, and the url tells it what to fetch. The credentials go in the auth tuple, and the comment about not receiving a job status and a results url but a direct JSON response describes the synchronous mode of the endpoint.

The output example makes the important point about what you get back. The content field holds a document, truncated in the example, and alongside it sit created_at, updated_at, page, url, job_id and status_code. There is no product title, no price and no rating field anywhere in the response.

So the service is a remote page fetcher with the markup preserved, and the phrase in the README that it lets you procure public data from any Lazada webpage is accurate but needs reading carefully. The data is public in the sense that the page is public, and extracting brands, item availability or shipping details from it is the job you still have to do, because the endpoint hands you the same HTML a browser would have received.

A documentation repository with a code examples folder

The repository is small, and its shape says what kind of artefact it is. The top-level entries are the README and a directory called code examples, and the README links to that directory for examples in other programming languages.

That is worth noting because it distinguishes this from the code-based tools in the same space. There is no library to install, no client to configure and no code to maintain. The repository is a reference implementation and a pointer to more of the same, and the service itself runs on the vendor's infrastructure at the realtime.oxylabs.io host.

The primary language recorded for the repository is Java, which is consistent with a multi-language examples directory, and the repository licence is recorded as unknown, with no licence file at the root. That is a practical difference from an open source scraper library, and it is worth noting for anyone planning to build a product on top of it.

The repository topics are the usual scraping set: lazada, lazada-scraper, lazada-scraper-api, lazada-scraping and lazada-web-scraper. The last push was on 2026-04-02, the repository is not archived and there are no GitHub releases, so the version of the service that the examples describe is not pinned by anything in the repository.

The commercial framing is present throughout. The README opens with a promotional banner linking to the vendor, carries a Discord badge and a YouTube badge, and the closing paragraph invites questions to the support team through live chat or a support email address. The repository is a funnel as much as a guide, and evaluating the API on its technical merits means separating the two.

The output payload is a job record with a content field

The response object is worth reading field by field, because it tells you what the service considers a unit of work.

Each entry in the results array has a content field holding the document that was fetched, a created_at and an updated_at pair, a page number, the url that was requested, a job_id and a status_code.

The job_id is the interesting one. It identifies the fetch, which means the service tracks requests individually even in the mode where it returns the result inline rather than pointing you at a results URL. The README comment says exactly that: instead of a response with job status and a results url, this returns the JSON response with the result. So there are two modes in the product, and the one documented here is the synchronous one.

The two timestamps are also different in kind, and they are not the same field. created_at is when the job was recorded and updated_at is when the record last changed, which for a one-shot fetch is a small gap between arrival and processing. The values in the example are a few minutes apart on the same date, which fits that reading.

The status_code is the upstream HTTP status, so a page that returns 404 or 403 to the fetcher comes back as a successful API call carrying a failure status. A consumer that only checks whether the response body parsed will treat a block page as a page, and the status_code is the field that distinguishes the two. That is a small detail with a real consequence, and it is visible in the sample output rather than buried in documentation.

The content itself is truncated in the example with an ellipsis, and it is a full document rather than a fragment, starting with a doctype and a head element. Whatever the fetcher did to get the page, the result handed back is markup you could save to a file and open in a browser.

What it is for, and where the work actually is

The README states the purpose directly: with the Lazada Scraper you can seamlessly procure public data from any Lazada webpage, so you can gather product information such as brands, item availability or shipping details to understand the market dynamics and outperform your rivals.

Those three examples are the interesting part, because each one implies a different kind of page. A brand listing is a category page, item availability is a product detail page, and shipping details are in the delivery information on a product page. All three are pages the same endpoint can fetch, which is the point of a universal fetcher rather than a set of purpose-built extractors.

The trade is that the endpoint does not know what a brand is. It fetches a URL and returns what the server sent. Turning that into a brand list means parsing the category page yourself, and pulling availability means finding the right element in a product page whose markup you do not control and which can change without notice. The parsing work is the same work you would have done with a local HTTP client, except that now it happens on the vendor's side of the connection.

What the service does buy you is the fetching. A marketplace page is a page that will resist naive requests, and the fact that the endpoint is called universal, with a source field that could be another value, suggests the service has other modes for that. The README does not document what other source values exist, so what is documented here is one mode: fetch this URL and give me the HTML.

That is also the honest limit of what this repository can tell you. The output example shows a status_code of 200 and a job_id, so you can tell whether the fetch worked, and you can see the page number. What you cannot see from the documentation is how the service behaves on a page that requires JavaScript, how it handles a page that blocks the request, or what its throughput looks like under load, because none of that is in the visible text.

One request per URL, and no mention of listing

The request model has a property that shapes what you can build on it, and it is visible in the payload structure.

The url is a single string, and the response carries a page field set to 1 in the example. There is no list parameter, no start page, no crawl option and no way to ask for many URLs in one call. The stars-style aggregation that other services offer is not here, and neither is a search endpoint across the marketplace.

So the shape of a consumer is a loop over URLs, one request each. For a price monitoring job over a set of product pages, that is workable. For anything that needs to discover pages, such as walking a category tree or following links, the discovery has to happen on your side, and every discovered URL costs a request.

The page field in the response suggests pagination is a concept the service knows about, even though the documented request does not use it, and the one-liner note that the results URL is not returned in this mode implies another mode does return one. Those are hints rather than documentation.

For an engineer evaluating this, the practical questions are therefore concrete. How many requests can you make in a minute on your plan, what happens when a fetch fails, whether the returned HTML is the same for every call or varies, and whether the service handles the redirects and locale routing that a marketplace applies. The repository answers none of those, and a trial against your own target URLs is the only way to find out.

Editorial conclusion

Lazada Scraper API is worth a look if you need to read Lazada pages from a script without maintaining a scraper, because the request model is trivial and the endpoint handles the fetching. It is the wrong tool if you want structured product fields rather than markup, because what comes back is the HTML of the page, so the parsing is still your problem, and it is the wrong tool if you need a self-hosted component, since the service is run by Oxylabs. Before you build on it, verify three things yourself: that a page you want is reachable through the endpoint, since the model is one request per URL with no mention of listing or crawling many pages, that the credentials you need are the ones your account provides, since the example uses a user and password pair that is a placeholder, and that the terms of the service you are pulling permit what you are doing with the data, because the README frames the output as public data but says nothing about how it may be used.

Frequently asked questions

Official sources

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