The WooCommerce Scraper API Guide

What the WooCommerce Scraper API is

The WooCommerce Scraper API is an HTTP endpoint that extracts products, categories, and reviews from any reachable WooCommerce store and returns them as predictable JSON. You send a request with a store URL and the parameters you care about, and you get back a normalized payload: titles, prices, SKUs, stock status, images, descriptions, category trees, and customer reviews. Because it is a hosted service, you never run a headless browser, rotate proxies, or update parsers when a theme changes.

It is built for people who write code and want catalog data on demand:

• Developers building price monitors, comparison sites, dropshipping tools, or internal dashboards who need a stable JSON contract instead of brittle scraping scripts.
• Agencies migrating client catalogs, syncing inventory across platforms, or auditing competitor stores at scale without standing up their own infrastructure.
• Automation builders wiring catalog data into spreadsheets, ETL pipelines, n8n or Zapier flows, and scheduled jobs that keep an external system in sync with a live store.

The value proposition is straightforward. Writing your own scraper means owning a headless browser, a proxy pool, retry logic, and a parser that breaks the day a store switches themes. A hosted scraping API removes all of that. You make a single authenticated HTTP request and receive structured data, while the maintenance burden of keeping extraction working across thousands of differently-configured stores sits with the service rather than with you. That trade is what makes the API attractive to teams who would rather spend their time on their own product than on scraping plumbing.

If you would rather not write any code at all, the same engine powers our no-code web scraper, where you paste a URL and download a CSV. The API is the programmatic layer on top of that engine, and the full interactive reference lives in the developer documentation.

Authentication and API keys

Every request to the WooCommerce Scraper API is authenticated with an API key. You create keys in your dashboard under Profile > API Keys. Each key carries its own permissions and usage counters, so you can issue a separate key per project or per client and revoke any one of them without affecting the others.

Send the key in the Authorization header as a bearer token:

Authorization: Bearer wcs_live_xxxxxxxxxxxxxxxxxxxxxxxx

If a bearer header is awkward in your environment, the API also accepts the key in an X-API-Key header instead. Use whichever fits your HTTP client; both are equivalent.

Test keys vs live keys

There are two key types, and you can tell them apart by their prefix:

• Test keys start with wcs_test_. They run against a free sandbox so you can integrate, write tests, and explore the response shape without a paid plan. Test keys have lower rate limits and are meant for development, not production traffic.
• Live keys start with wcs_live_. They run real extractions at full speed and require an active plan. Use them once your integration works and you are ready to scrape production stores.

A key is shown in full only once, at the moment you create it. The dashboard stores a hashed version, so copy the key into your secret manager or environment variables right away. If you lose it, you cannot recover the original value; you revoke the old key and generate a new one. Never commit keys to source control or expose a live key in client-side JavaScript, since anyone holding it can spend your quota.

Endpoints

The API is versioned under /api/v1/. There are two families of endpoints: synchronous reads that return a single page of data immediately, and asynchronous jobs that crawl an entire store in the background.

Synchronous reads

These return one page of results per call. Pass the target store and a per_page value (up to 100) plus a page number to paginate.

• GET /api/v1/products returns products with prices, SKUs, stock status, images, and descriptions.
• GET /api/v1/categories returns the store's category tree with names, slugs, parents, and product counts.
• GET /api/v1/reviews returns customer reviews with rating, author, date, and body.
• GET /api/v1/usage returns your current consumption against your monthly quota and rate limits.

Async jobs

When you need a whole catalog rather than a single page, create a job instead of paging manually.

• POST /api/v1/jobs starts an export job for a full store and returns a job id.
• GET /api/v1/jobs/{id} returns the job status (queued, running, completed, or failed) and progress.
• GET /api/v1/jobs/{id}/results returns the extracted data once the job is complete, paginated so large catalogs stream cleanly.

Response envelope

Every successful response uses the same envelope so your parsing code stays uniform across endpoints. Each payload contains a data array (or object) with the result, a meta object with pagination and counts, and a request_id string you can quote in support tickets to trace a specific call:

{
  "data": [ { "name": "Sample product", "price": "29.00", "sku": "ABC-1" } ],
  "meta": { "page": 1, "per_page": 100, "total": 240 },
  "request_id": "req_8f3a1c9e"
}

Errors follow the same convention. A failed call returns the matching HTTP status (for example 401 for a missing or invalid key, 422 for bad parameters, 429 when you are rate limited) together with a JSON body that carries a machine-readable error code and a human-readable message, plus the same request_id so a failed call is just as traceable as a successful one. Designing around one consistent envelope means you write your success and error handling once and reuse it across every endpoint.

The complete list of fields, query parameters, and error codes is documented in the interactive API reference, and the how-to tutorial shows the same calls in cURL, PHP, JavaScript, and Python.

Rate limits and quotas

Rate limits protect both the API and the stores it reads, and they differ by key type:

• Live keys: 120 requests per minute.
• Test keys: 20 requests per minute, since the sandbox is for development.

Every response includes headers that tell you exactly where you stand, so you do not have to guess or hardcode the numbers:

• X-RateLimit-Limit: the ceiling for the current window.
• X-RateLimit-Remaining: how many requests you have left in this window.
• X-RateLimit-Reset: when the window resets, so you know how long to wait.

If you exceed the limit, the API returns HTTP 429 Too Many Requests with a Retry-After header telling you how many seconds to back off. A well-behaved client reads Retry-After and pauses rather than hammering the endpoint. On top of the per-minute limit, live keys include a monthly quota of 100,000 calls, which is enough to keep large catalogs in sync many times over. Poll GET /api/v1/usage at any time to see how much of your quota you have spent.

Async export jobs and webhooks

Large stores can hold thousands of products, and fetching them one synchronous page at a time is slow and ties up your own process. Async export jobs solve this. You submit one request describing what you want, the API crawls the store in the background, and you collect the results when they are ready.

The flow has three steps:

• Create the job with POST /api/v1/jobs, passing the store URL and the resource you want (products, categories, or reviews). You get back a job id immediately.
• Poll GET /api/v1/jobs/{id} until the status is completed. The response reports progress so you can show a percentage or estimate.
• Download the data from GET /api/v1/jobs/{id}/results, paging through the result set for very large catalogs.

Polling is simple, but if you would rather not poll at all, jobs support an optional webhook callback. Include a callback URL when you create the job and the API will send an HTTP POST to that URL the moment the job finishes, with the job id and final status in the body. Your endpoint then fetches the results and writes them wherever they belong. This is the pattern to use for scheduled, hands-off syncs. The dedicated guide on how to automate WooCommerce exports walks through scheduling, retries, and idempotent webhook handling in detail.

Resilient extraction

A scraping API is only useful if it keeps working when stores are configured in unusual ways. Many WooCommerce sites lock down or disable the default /wp-json/ REST routes for security or performance reasons, which breaks naive integrations that assume that path is always open. The WooCommerce Scraper API is built to degrade gracefully instead of failing.

For each store, the API tries multiple extraction strategies in order until one succeeds:

• The WooCommerce Store API, the modern read-only endpoint that returns clean product JSON when it is available.
• The legacy REST path via ?rest_route=, which still works on many stores where pretty permalinks for the API are turned off.
• Product sitemaps plus JSON-LD, where the API reads the store's sitemap to discover product URLs and parses the structured data embedded in each page. This works even when every REST surface is closed.

Because the fallback chain is handled on our side, your code does not change. You call the same endpoint and receive the same response envelope regardless of which strategy actually produced the data. This is the core reason a dedicated scraping API outperforms calling a store's API directly; see WooCommerce REST API vs a scraping API for a full comparison, and our roundup of the best WooCommerce scraper tools for how this approach stacks up.

Pricing

Pricing is deliberately simple. The Developer plan is 79 dollars per month and is all-inclusive. There are no per-endpoint charges and no separate add-ons to assemble. One plan unlocks the full API (synchronous reads, async jobs, webhooks, and the 100,000 live-call monthly quota) along with every web and browser-extension feature in the product.

That means a single subscription covers programmatic access for your code, the no-code web tool for quick one-off exports, and the extension for grabbing data while you browse. Before you commit, you can build and test the entire integration for free with a wcs_test_ sandbox key. See the full breakdown on the pricing section.

Quickstart

Here is the smallest possible request: fetch the first page of products from a store, 100 at a time, using a bearer key. Swap in your own key and target URL and you have a working integration.

curl "https://woocommerce-scraper.com/api/v1/products?store=https://example-shop.com&per_page=100&page=1" \
  -H "Authorization: Bearer wcs_live_xxxxxxxxxxxxxxxxxxxxxxxx"

The response comes back in the standard envelope with a data array of products, a meta object for pagination, and a request_id. To pull the whole catalog instead of one page, switch to an async job. For the same call in PHP, JavaScript, and Python, follow the step-by-step tutorial, and create your key from the developer dashboard.

Frequently asked questions

Do I need a paid plan to start building?

No. You can create a free wcs_test_ sandbox key and build your entire integration against it, including reading the full response envelope and testing your error handling. You only need a live wcs_live_ key, which requires the Developer plan, when you are ready to scrape production stores at full speed.

What happens if a store has disabled its WordPress REST API?

The API still works. It automatically falls back across the WooCommerce Store API, the legacy ?rest_route= path, and product sitemaps with JSON-LD parsing. Your request and the response shape stay the same no matter which method ultimately returns the data.

How do I scrape an entire store rather than a single page?

Use the async jobs endpoints. Create a job with POST /api/v1/jobs, poll GET /api/v1/jobs/{id} until it is complete (or supply a webhook callback so you are notified automatically), then download the data from GET /api/v1/jobs/{id}/results.

What are the rate limits and quota?

Live keys allow 120 requests per minute with a monthly quota of 100,000 calls; test keys allow 20 requests per minute. Every response includes X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers, and a 429 response carries a Retry-After value telling you how long to wait.

How much does the API cost?

The Developer plan is 79 dollars per month and is all-inclusive. It covers the full API plus every web and browser-extension feature, with no per-call or per-endpoint surcharges beyond the included 100,000 monthly live calls.