WooCommerce REST API Authentication: API Keys, Requests, and Troubleshooting

WooCommerce REST API authentication normally uses a consumer key and consumer secret generated for a WooCommerce user. For an HTTPS store, the simplest pattern is HTTP Basic Authentication: send the consumer key as the username and the consumer secret as the password.

Quick answer: authenticate a WooCommerce REST API request

Create a read-only API key in WooCommerce, export the values into environment variables, then make a small read request:

export WC_URL="https://example.com"
export WC_CONSUMER_KEY="ck_your_consumer_key"
export WC_CONSUMER_SECRET="cs_your_consumer_secret"

curl --user "$WC_CONSUMER_KEY:$WC_CONSUMER_SECRET" \
  "$WC_URL/wp-json/wc/v3/products?per_page=1"

A successful request should return an HTTP success status and a JSON array. The array may be empty if the store has no products; that still verifies that the endpoint accepted the credentials and processed the request.

Do not place real keys in a terminal recording, screenshot, public issue, browser-based frontend application, or repository. Before publishing an integration, confirm the endpoint and authentication behavior for the installed WordPress, WooCommerce, web server, and proxy configuration. These details can be version- and environment-sensitive.

Requirements and version considerations

• A working WordPress site with WooCommerce installed and its REST API available.
• An administrator account that can create REST API keys, or access granted by the site administrator.
• A WooCommerce user account to associate with the key. Requests act with that user’s capabilities.
• An HTTPS URL for production API calls.
• The correct REST route for the WooCommerce API version your integration targets, commonly under /wp-json/wc/v3/.

HTTPS protects credentials in transit. It is also the normal condition for using Basic Authentication safely. Authentication can be affected by the WordPress REST configuration, WooCommerce version, web server rules, security plugins, caches, load balancers, and reverse proxies. Check the official WooCommerce and WordPress documentation for your installed versions before treating an example as production configuration.

Create WooCommerce REST API keys

1. In the WordPress admin area, open WooCommerce > Settings > Advanced > REST API.
2. Select Add key.
3. Add a useful description, such as inventory-sync-production.
4. Select the user whose permissions the integration should use.
5. Choose an access level: Read, Write, or Read/Write.
6. Generate the key, then copy the consumer key and consumer secret into protected server-side storage.

Use Read for an integration that only retrieves products, orders, or reports. Use Write only when it must change data. Use Read/Write when both are genuinely required. Permission selection is not a substitute for choosing an appropriately restricted WooCommerce user: the user associated with the key still determines what the request is allowed to do.

Create separate keys for separate applications and environments. That makes a compromised or retired integration easier to isolate. Treat the consumer secret as a password: it may only be fully shown when the key is created, so save it securely at that point.

Choose an authentication method

HTTPS Basic Authentication

This is usually the clearest option for server-to-server integrations. Put the consumer key in the Basic Auth username position and the consumer secret in the password position. Most HTTP clients support this directly, and the credentials are sent in an Authorization header.

Query-string credentials

Some environments use credentials in the URL, for example ?consumer_key=...&consumer_secret=.... This can help with compatibility when an upstream component strips the Authorization header, but it has a meaningful exposure risk. URLs can appear in browser history, proxy logs, application logs, analytics tooling, and error reports. Do not use this method casually, and never use it in client-side code.

OAuth 1.0a signing

OAuth 1.0a is a signed-request option for environments that require it, particularly where Basic Authentication is not viable. It adds signing, nonce, timestamp, and encoding requirements, so it is not the default choice for a normal HTTPS server-to-server request. Prefer Basic Authentication unless your hosting or integration constraints specifically require OAuth signing.

Request examples with cURL and application code

Read request with cURL

curl --silent --show-error --fail-with-body \
  --user "$WC_CONSUMER_KEY:$WC_CONSUMER_SECRET" \
  -H "Accept: application/json" \
  "$WC_URL/wp-json/wc/v3/products?per_page=1"

Keep the base URL free of a trailing slash in WC_URL so the constructed URL contains one slash before wp-json. If your store is installed in a subdirectory, include that subdirectory in the base URL. Let your HTTP client URL-encode query values rather than manually concatenating untrusted values into a URL.

Server-side JavaScript example

The following Node.js example uses the built-in fetch API. It runs on a server; it must not be bundled into browser code.

const baseUrl = process.env.WC_URL.replace(/\/$/, "");
const key = process.env.WC_CONSUMER_KEY;
const secret = process.env.WC_CONSUMER_SECRET;

if (!baseUrl || !key || !secret) {
  throw new Error("WooCommerce API environment variables are missing");
}

const authorization = Buffer
  .from(`${key}:${secret}`)
  .toString("base64");

const response = await fetch(`${baseUrl}/wp-json/wc/v3/products?per_page=1`, {
  headers: {
    Accept: "application/json",
    Authorization: `Basic ${authorization}`
  }
});

const body = await response.json();

if (!response.ok) {
  throw new Error(`WooCommerce request failed: ${response.status}`);
}

if (!Array.isArray(body)) {
  throw new Error("Unexpected WooCommerce response structure");
}

console.log(`Authenticated successfully; received ${body.length} product record(s).`);

Write request pattern

A write-capable key is required for changes. This example shows the request shape only; adapt the endpoint and fields to the resource you intend to create or update.

curl --request POST \
  --user "$WC_CONSUMER_KEY:$WC_CONSUMER_SECRET" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  --data '{"name":"Example product","type":"simple","regular_price":"19.99"}' \
  "$WC_URL/wp-json/wc/v3/products"

For every call, check both the HTTP status and the response structure. A JSON response alone is not proof of success: WordPress can return JSON error objects for failed requests.

Secure credential handling

• Store keys in environment variables, a secret manager, or protected server-side configuration.
• Exclude local secret files from source control and avoid printing secrets in debug output.
• Use a dedicated WooCommerce user and the narrowest practical key permission.
• Never expose keys in public JavaScript, mobile client code, screenshots, support tickets, or shared documents.
• Review application, proxy, CI/CD, and server logs for accidentally recorded URLs or Authorization headers.
• Revoke keys for retired integrations, and replace them if a secret may have been exposed.

Rotation is easiest when every integration has its own key. Create a replacement, update the protected configuration, verify a minimal read request, then revoke the old key once the integration is using the new one.

Troubleshoot authentication failures

Start with the smallest possible read-only request. If it fails, do not debug product payload fields or an automation workflow yet. First verify the full URL, HTTPS certificate, generated key, associated user, and key permission.

A common issue behind a reverse proxy is that the Authorization header is removed before PHP or WordPress receives it. Security plugins, web application firewalls, caching layers, and host-level rules can also block REST routes or Basic Auth. Compare a direct server-side request with the request reaching the public domain, then inspect the relevant proxy and server configuration. Query-string credentials may help isolate a stripped-header problem, but avoid leaving that workaround in a production workflow without addressing its disclosure risk.

Connect authenticated requests to integrations

The same credentials can be used by server-side scripts, integration platforms, and automation tools. Save them once in the platform’s protected credential store or environment configuration rather than copying them into every workflow step. Authentication confirms API access; it does not validate webhook signatures, payload handling, retry behavior, idempotency, or your business rules.

For event-driven workflows, continue with WooCommerce Webhooks in 2026: Modern Automation Patterns. To build a practical automation after your API test succeeds, see How to Connect WooCommerce to n8n Step by Step.

FAQ and maintenance checklist

Are WooCommerce REST API keys the same as WordPress application passwords?

No. They are separate credential systems with different setup flows and intended API use. Use WooCommerce REST API keys for WooCommerce REST API authentication unless your specific integration documentation requires another mechanism.

Can a read-only key create or update store data?

No. Use a write-capable key only for workflows that must make changes, and keep the associated user appropriately restricted.

Should I send credentials to frontend code or third parties?

Do not place WooCommerce consumer secrets in frontend code. Give a third party only a dedicated, least-privilege key when there is a clear trust and operational need, and revoke it when that access ends.

Pre-production checklist

• Use the correct HTTPS base URL and REST endpoint.
• Create a dedicated key for the specific integration.
• Select the minimum permission required.
• Store credentials only in protected server-side configuration.
• Verify a minimal read request, including its status and JSON shape.
• Test an allowed write operation separately if the integration needs one.
• Document where to revoke or rotate the key and review behavior after WooCommerce, WordPress, hosting, proxy, or integration changes.