WooCommerce REST API Security: Keys, Scopes, and What to Restrict

What a WooCommerce API key actually is

Any time you connect a third-party tool to WooCommerce — an inventory sync app, a custom mobile storefront, a Zapier automation, an accounting integration — that tool talks to your store through the WooCommerce REST API, authenticated with a Consumer Key and Consumer Secret pair generated under WooCommerce → Settings → Advanced → REST API. That key pair is a standing, programmatic credential. Whatever holds it can read or write store data indefinitely, with no login prompt and no session that expires the way a browser login does.

The permission level most people get wrong

When you generate a key, WooCommerce asks you to pick one of three permission levels: Read, Write, or Read/Write. It's tempting to read this as fine-grained control — "Read" for a reporting tool, "Write" for something that only creates orders — and to assume that's the whole story. It isn't.

Here's the part that catches people out: a WooCommerce API key is also generated for a specific WordPress user, and per WooCommerce's own documentation, "use of the REST API with the generated keys will conform to that user's WordPress roles and capabilities." The Read/Write setting controls what kind of operation the key can perform — but the actual scope of what it can touch is inherited entirely from whichever WordPress user account the key is tied to. Generate a key against your own administrator account, set it to "Read," and that key can still read every order, every customer record, and every setting an administrator can see. The permission dropdown was never a substitute for choosing the right user.

The fix: a dedicated, minimally-privileged user

The practical takeaway is simple, and most stores skip it: don't generate integration keys against your own admin account or a shared "store owner" login. Create a separate WordPress user specifically for each integration — typically a Shop Manager role, which already covers the order/product/customer access most integrations actually need without full administrator reach — and generate the key against that user instead. An inventory-sync tool that only needs to read stock levels and update quantities doesn't need a key that can also see every customer's billing address or change site settings, and with the right dedicated user in place, it won't.

Why a leaked key is a different problem than a leaked password

A stolen admin password usually shows up somewhere: a login notification, a "new device" alert, a session you don't recognize in your account activity. An API key doesn't work that way. It's typically pasted into a third-party app's settings screen, saved in a spreadsheet during setup, or — a genuinely common mistake — committed into a code repository for a custom integration and left there in the project's history even after someone "removes" it from the current file. Anyone who finds it can make authenticated requests against your store indefinitely, with no login event to notice and no obvious symptom beyond the data itself moving. This is exactly the kind of standing, unmonitored access that makes stolen or forgotten credentials one of the quieter ways a store's data actually walks out the door, distinct from the more visible malware and skimming risks covered elsewhere on this site.

Key hygiene: the audit most stores never do

API keys accumulate. A developer generates one to test an integration that never shipped. An agency sets one up for a project that ended a year ago. A plugin that was uninstalled left its key active and forgotten. None of these get cleaned up on their own, because unlike a plugin, an unused API key doesn't show up anywhere in your dashboard nagging you about it.

Periodically, walk through WooCommerce → Settings → Advanced → REST API and ask, for every key listed: is this integration still actually running? If you can't answer confidently, that's the signal to revoke it — WooCommerce lets you do this directly from the same screen with a "Revoke" action, no code changes required. It's also worth remembering that a key stops working automatically if the WordPress user it's tied to gets deleted, which is one more reason the offboarding discipline covered in offboarding a client site securely should specifically include a pass through any API keys that integration touched, not just user logins.

Where this connects

An API key is, in the end, just another way into the same data covered in how to secure WooCommerce customer data — the difference is that it's a door most store owners never think to check is locked. And the same scrutiny that applies to vetting a WooCommerce extension before installing it applies just as much to deciding how much API access that extension actually needs once it's in.