WooCommerce REST API 401 Unauthorized: Fix Broken Sync
Your Zapier flow, mobile POS app, or inventory sync tool was pulling orders from WooCommerce just fine, and then one morning every request starts coming back with 401 Unauthorized or woocommerce_rest_authentication_error. Nothing in the WooCommerce settings looks different. Here's what's actually going on with the REST API's authentication, and how to get integrations talking to your store again.
How WooCommerce API keys actually work
WooCommerce's REST API (/wp-json/wc/v3/) is separate from the general WordPress REST API that Gutenberg and most plugins use. It authenticates with its own consumer key and secret pair, generated under WooCommerce > Settings > Advanced > REST API. Each key pair is tied to two things people forget about:
- A specific WordPress user account - the key inherits that user's role and capabilities, not some separate API-only identity.
- A permission level - Read, Write, or Read/Write, set when the key was created and impossible to change without regenerating it.
Over HTTPS, most integrations authenticate with HTTP Basic Auth - the consumer key as the username, the secret as the password. Over plain HTTP (which you shouldn't be running anyway), WooCommerce falls back to OAuth 1.0a signatures, which is where a lot of the stranger errors below come from.
Symptom: "401 Unauthorized" with a fresh, correctly-copied key
Cause: almost always one of three things - the key was pasted with a trailing space or line break, the request is missing the ck_/cs_ prefixes because a script stripped them, or the site is serving the request over HTTP while the key was generated expecting HTTPS-based Basic Auth.
Fix: test the key in isolation before blaming the integration platform:
curl -s -o /dev/null -w "%{http_code}\n" \
-u ck_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:cs_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
https://yourdomain.com/wp-json/wc/v3/productsA 200 here means the key is fine and the problem lives in how the integration tool is sending it - usually as a query string parameter when the endpoint now requires header-based auth behind a proxy or CDN that strips query strings before they reach PHP.
Symptom: it works from Postman but fails from Zapier, Make, or a custom script
Cause: most no-code platforms send credentials as URL parameters (?consumer_key=...&consumer_secret=...) instead of an Authorization header. That only works over HTTPS, and it can get silently dropped by:
- A security plugin or ModSecurity rule that flags long query strings as suspicious and returns a generic 401/403 instead of the real error.
- A caching layer or CDN (Cloudflare, Sucuri) that caches the response without the query string, so the platform gets a cached page instead of hitting your server at all.
Fix: switch the integration to send credentials as a Basic Auth header where the platform allows it - it's the same key pair, just a different transport, and it skips both problems above. If you're stuck with query-string auth, add a Page Rule or cache bypass for /wp-json/wc/* so the CDN never caches those requests, and check /usr/local/apache/logs/error_log (via cPanel's Errors page) for a ModSecurity rule ID blocking the request.
Symptom: a key that worked for months suddenly stopped
Cause: the WordPress user the key is tied to was deleted, demoted below the required role, or had two-factor authentication forced onto their account by a security plugin. Since the key inherits that user's permissions live on every request, the key doesn't need to be touched for it to stop working - the user just needs to change underneath it.
Fix: in WooCommerce > Settings > Advanced > REST API, check the "User" column next to the key. If that account is gone or downgraded, you have to generate a brand-new key against a valid user - there's no way to reassign an existing key to a different account.
Symptom: "oauth_signature_invalid" or "Invalid signature - provided signature does not match"
Cause: this only shows up on non-HTTPS sites falling back to OAuth 1.0a, and it's almost always server clock drift. OAuth signatures include a timestamp, and if your VPS clock has drifted more than a few minutes from real time, WooCommerce rejects the signature as expired or invalid even though the credentials are correct.
Fix - the real one: move the site to HTTPS and use Basic Auth instead of OAuth entirely; it removes this whole failure class. Fix - if you're stuck on HTTP short-term: check and correct server time:
timedatectl status
sudo chronyc sources
sudo systemctl restart chronydCommon causes at a glance
| What you see | Most likely cause | Fastest fix |
|---|---|---|
| 401 on every request, key just created | Trailing space or missing ck_/cs_ prefix | Re-copy the key, test with curl -u |
| Works in Postman, fails in the platform | Query-string auth blocked or cached | Switch to Basic Auth header; bypass cache on /wp-json/wc/* |
| Key stopped working with no changes made | Linked WP user deleted or demoted | Create a new key against a valid, dedicated user |
| Invalid signature errors | OAuth 1.0a + server clock drift on HTTP sites | Move to HTTPS; fix NTP/chrony sync |
| Intermittent 401s under load | Rate limiting or LVE resource limit misread as auth failure | Check cPanel resource usage; stagger sync intervals |
Setting up keys so this doesn't happen again
- Create a dedicated WordPress user just for API integrations - never tie a key to someone's personal admin account that might get deleted during offboarding.
- Give it the Shop Manager role, not Administrator, and set the key's permission to exactly what the integration needs (Read-only for a reporting tool, Read/Write only if it actually creates or updates orders).
- Keep a simple record - which key belongs to which platform, created on which date - so a broken integration takes two minutes to diagnose instead of twenty.
- Make sure the site is on HTTPS everywhere, including the REST API base URL, so you never depend on OAuth 1.0a at all.
If you're chasing a REST error that isn't WooCommerce-specific - Gutenberg failing to save, Elementor stuck loading - that's the general /wp-json/wp/v2/ API and a different set of causes (security plugin restrictions, a stray .htaccess block), worth checking separately from the steps here.
FAQ
No. A key stays valid indefinitely until someone revokes it, deletes it, or the linked WordPress user is removed or demoted. If a key that's been working for months suddenly fails, look at the user account before assuming the key itself went bad.
Technically yes, via OAuth 1.0a signatures, but it's slower to debug and sensitive to server clock drift. Every current WooCommerce install should be on HTTPS anyway, which lets you use simple Basic Auth instead.
Postman usually sends credentials as a Basic Auth header by default, while many no-code platforms send them as URL query parameters. Query parameters can get stripped by caching layers or flagged by security rules that a direct header request sails past.
There's no hard limit in WooCommerce itself. Create one key per integration rather than reusing a single key everywhere - it makes revoking access for one broken or retired tool a lot cleaner.
No. WooCommerce ships its own versioned API (wc/v3) with its own consumer key/secret auth, layered on top of the general WordPress REST API (wp/v2) that most page builders and Gutenberg use. They can fail independently of each other.
Frequently asked questions
Do WooCommerce REST API keys expire on their own?
No. A key stays valid indefinitely until someone revokes it, deletes it, or the linked WordPress user is removed or demoted. If a key that's been working for months suddenly fails, check the user account before assuming the key itself went bad.
Can I use the WooCommerce REST API without HTTPS?
Technically yes, via OAuth 1.0a signatures, but it's slower to debug and sensitive to server clock drift. Every current WooCommerce install should be on HTTPS anyway, which lets you use simple Basic Auth instead.
Why does my key work in Postman but not in my actual integration?
Postman usually sends credentials as a Basic Auth header by default, while many no-code platforms send them as URL query parameters, which can get stripped by caching layers or flagged by security rules.
How many API keys can a WooCommerce store have?
There's no hard limit. Create one key per integration rather than reusing a single key everywhere - it makes revoking access for one broken or retired tool much cleaner.
Is this the same as the WordPress REST API that plugins like Elementor use?
No. WooCommerce ships its own versioned API (wc/v3) with its own consumer key/secret auth, layered on top of the general WordPress REST API (wp/v2) that most page builders and Gutenberg use. They can fail independently of each other.