WooCommerce REST API vs scraping: which one should you use?

REST API, Store API and scraping API: what they are

Before comparing them, it helps to be precise about three distinct things that often get lumped together under the phrase "the WooCommerce API".

The official WooCommerce REST API lives at /wp-json/wc/v3. It is the administrative interface for a store. You authenticate with a consumer key and consumer secret that you generate in WooCommerce under Settings, Advanced, REST API, and those keys are tied to a WordPress user with the right permissions. With it you get full read and write access to the store: products, variations, orders, customers, coupons, refunds and more. It is powerful, but it only works on a store where you are an administrator and can create those keys.

The WooCommerce Store API lives at /wp-json/wc/store. It is a newer, mostly public, read-oriented interface designed to power the storefront and the block-based cart and checkout. Anyone can call it without authentication for catalog data, which makes it useful for reading public products. The trade-off is that it exposes far less than the admin REST API, it is read-only for catalog purposes, and a store owner can disable it.

A third-party scraping API (the product behind this site) is a different category. Instead of authenticating against one store you own, you authenticate against our service with a single Bearer key and ask it to read any public WooCommerce store. You point it at a URL and it returns normalised product data, prices, images, variations and reviews. You never need the target store's admin credentials, because the scraping API only reads what is already public, then adds resilience so it keeps working even when the standard endpoints are blocked.

Side-by-side comparison table

Here is how the three options line up across the criteria that usually decide which one you reach for.

When the official REST API is the right choice

If you own the store and you hold administrator access, the official WooCommerce REST API is almost always the correct tool, and a scraping API would be the wrong one. The official API is built for exactly this case and a scraper cannot match it on completeness or write access.

Reach for the official REST API when:

• You need to write data back: create or update products, adjust stock levels, process refunds, manage coupons or push order status changes. A scraping API only reads, so write operations are off the table.
• You need private admin data that is never exposed publicly: customer records, full order details, internal notes, cost fields or draft products.
• You are building an integration on your own store, such as syncing inventory to an ERP, connecting a fulfilment service, or feeding a dashboard you control end to end.
• You want transactional guarantees and an officially supported contract from the platform, with predictable field names and documented behaviour.

In short, the official API is the system of record for your own store. If you can generate consumer keys in wp-admin and you need write access or private data, use it. A scraping API can complement that workflow for outward-facing tasks, but it should never be your tool for editing the store you operate, because it does not write and it does not see anything that the store keeps private.

It is also worth noting that the official API gives you a stable, documented contract. Field names, pagination behaviour and error formats are specified by the platform, which matters a great deal when you are building a long-lived integration that other systems depend on. That stability is one of the strongest reasons to prefer it whenever it is actually available to you.

Where the official API falls short

The official REST API is excellent at what it was designed for, but it has hard boundaries that no amount of effort can push past.

It needs admin credentials. Consumer keys can only be created by someone with administrative access to the store. That single requirement rules out every use case where you do not control the store.

It cannot reach stores you do not own. If you are doing competitor price monitoring, market research, catalog aggregation or supplier imports, you have no way to get keys for those stores. The admin REST API is simply not an option there, by design.

It is frequently blocked. Even on stores you do own, the /wp-json/ route is a common target for lockdown. Security plugins, web application firewalls (WAFs) and hosting-level firewalls regularly restrict or disable it. When that happens, calls come back as rest_no_route, an empty response, or an outright 403 Forbidden. Some hosts disable the REST API by default for non-authenticated paths, and many WordPress hardening guides recommend turning it off.

The Store API can be disabled too. The public /wp-json/wc/store interface is convenient, but a store owner or a security plugin can turn off the entire REST surface, including the Store API. So relying on it for public reads is fragile: it works until the day someone hardens the site.

If you hit any of these walls, the official API stops being a viable path and you need a different approach. That is precisely the gap a scraping API fills.

When a scraping API wins

A scraping API is the better choice whenever you need public catalog data from stores you do not administer, or when the official endpoints are unavailable. It trades write access (which it does not offer) for reach and resilience.

The scraping API behind this site wins in these situations:

• Any public store, no admin access. You point the API at a store URL and it reads the public catalog. No consumer keys, no cooperation from the store owner required.
• Resilient fallback when /wp-json is disabled. Instead of failing the moment the standard REST route is locked down, it cascades through a chain of strategies: it first tries the Store API, then ?rest_route= (the query-string form of the REST API that some configurations still expose), and finally falls back to parsing product sitemaps plus the JSON-LD structured data embedded in each product page. If one layer is blocked, the next takes over.
• Variations resolved. Variable products with per-variation prices, attributes and stock are flattened into clean, usable records, so you do not have to stitch parent and child products together yourself.
• Simple Bearer-key auth. You authenticate once against our service with a single wcs_live_ key and call endpoints such as /api/v1/products. There is nothing to configure on the target store.

This is what makes it suited to competitor monitoring, store migrations, supplier and dropshipping imports, price tracking and any pipeline where you cannot or should not rely on the target store handing you admin keys. See the complete scraper API guide for endpoints and limits, the step-by-step tutorial for code, and our price scraper if monitoring is your goal.

Our recommendation

There is no single winner here, because the two tools answer different questions. The honest, decision-friendly rule of thumb is this:

• Use the official WooCommerce REST API when the store is yours, you can generate consumer keys, and you need write access or private admin data such as orders and customers. Nothing beats it for managing your own store internals.
• Use the scraping API when you need data from competitors or stores you do not own, when you are running a migration or a one-time catalog export, when you have no admin access, or when the official endpoints are blocked by a security plugin, a WAF or the host. In those cases the official API is not just inferior, it is unavailable.

Many teams use both. The REST API keeps their own store in sync with their back office, while the scraping API watches the market and pulls in external catalogs. They are complementary, not competing. If you are weighing options across the ecosystem, our roundup of the best WooCommerce scraper tools and our primer on web scraping add useful context.

A useful way to make the call quickly is to ask one question first: do you have administrator access to the store you want data from? If the answer is yes and you need to change anything, the official REST API is your answer. If the answer is no, or if you only need to read public catalog data at scale across many stores, the scraping API is the pragmatic choice and usually the only one that works. The Store API sits in between: handy for light, public reads on a front end you control, but too limited and too easily disabled to depend on for anything serious.

One last honest caveat worth stating plainly: a scraping API does not replace the platform's guarantees. It cannot give you transactional writes, it cannot see private data, and it depends on what a store chooses to expose publicly. We designed the fallback chain precisely so that the practical reality of disabled endpoints does not break your pipeline, but the right mental model is still that the official API owns your store and the scraping API observes the public web. Pick the one whose job matches yours.

Frequently asked questions

Can I use the official WooCommerce REST API on a store I do not own?

No. The official REST API at /wp-json/wc/v3 requires a consumer key and secret that only an administrator of that store can generate. If you do not control the store, a scraping API that reads public data is the only practical route.

What happens if a store disables /wp-json?

The official REST API and the Store API both stop responding, typically returning rest_no_route or a 403. The scraping API handles this by falling back: it tries the Store API, then ?rest_route=, then parses the product sitemap and JSON-LD on each product page, so it keeps returning data.

Does the scraping API let me write or update products?

No. The scraping API is read-only; it extracts public catalog data. If you need to create or modify products, orders or stock, that is a job for the official WooCommerce REST API on a store where you are an administrator.

How do I authenticate with the scraping API?

You use a single Bearer key in the format wcs_live_... sent in the Authorization header, and call endpoints such as /api/v1/products. There is no per-store configuration; you simply pass the target store URL as a parameter.

Which one is better for competitor price monitoring?

The scraping API, without question. Competitors will not give you admin keys to their stores, so the official REST API is simply not an option. A scraping API reads their public prices and variations and keeps working even if they harden their endpoints.