Zyte API is not one kind of scraper request. It can retrieve a raw HTTP response, run a managed browser, expose that browser to Playwright or Puppeteer, or extract structured data from a page. Those modes look different to the website being accessed.
What Zyte API does
A customer sends a target URL to one API endpoint and specifies the output it needs. Zyte API can make an HTTP request, render the page in a managed browser, perform browser actions, or run automatic extraction for supported page types. Its usage documentation also describes geolocation, IP selection, cookies, and client-managed or server-managed sessions.
For workflows that need direct browser control, Zyte exposes a managed headless browser over the Chrome DevTools Protocol (CDP). Existing Playwright or Puppeteer code can connect to that browser while Zyte handles the browser infrastructure and proxy routing. This differs from a normal browser request, where Zyte performs the requested actions and returns the result.
Zyte's history is closely connected to Scrapy, the open-source Python crawling framework. Current Zyte documentation provides a scrapy-zyte-api integration, but Zyte API can also be called from Python, other HTTP clients, or proxy-compatible software.
How it is used for web data collection
The API covers several jobs that otherwise require separate components. A simple page can be fetched as an HTTP response. A JavaScript-heavy page can be rendered in a browser. Automatic extraction can return structured records for products, articles, jobs, search results, and other documented page types.
Zyte also supports a proxy mode for existing clients. The proxy-mode documentation makes an important distinction: proxy mode has lower integration overhead, but it does not expose every feature of the HTTP API. Automatic extraction and server-managed sessions, for example, belong to the HTTP API.
What a target website sees
There is no single request shape for all Zyte usage. An HTTP request, a browser-rendered request, a live CDP session, and proxy mode expose different behavior to the target. The selected proxy type, location, and session settings can change the network path and continuity between requests. Any rule that assumes "Zyte always looks like this" starts from a false premise.
This is why "block one IP" is not a complete response. It may stop the address observed today without identifying the automation or the work it is carrying out. A browser-only rule has the opposite gap when the retrieval path does not use a browser.
The stronger approach is to combine available connection, request, identity, browser, and behavior evidence. Then apply policy according to the requested resource and the activity around it. For the browser-rendered and CDP modes, the guide on how sites detect automated browsers covers the browser layer of that evidence.
Centinel benchmark result
In our September 2026 benchmark, Centinel detected Zyte.
The useful follow-up is specific: determine which pages or workflows the automation reached, whether it was authorized, and which response fits the site's policy. The scraping and AI crawler use case shows how Centinel applies that kind of per-route policy to scraping services such as Zyte.
What to check in your own traffic
When investigating possible Zyte-backed automation, examine:
- whether the traffic behaves like single-page retrieval, a crawl, or a live browser workflow;
- which public, expensive, or authenticated resources it requests;
- whether request sequences persist when IP addresses or browser properties change;
- whether a known partner, internal team, or approved data job accounts for it.
This avoids treating a network address as permanent identity and keeps approved automation separate from unwanted extraction.
Read What is web scraping? for a broader way to separate technical collection, site policy, and legal review.