Create a separate WooCommerce REST API key for each approved integration and grant only the access it needs. A reporting tool may need read access, while a stock synchronisation may require writes. Treat the key and secret as credentials to store data.
IN THIS ARTICLE
01 Define the integration's access
Confirm the application owner, required operations and the WordPress user whose capabilities will govern access. Use a dedicated, appropriately permitted account where practical. Read permission can still expose customer and order data, so it should not be treated as harmless public access.
02 Generate and install the key
- Open WooCommerce > Settings > Advanced > REST API.
- Add a key with a description that identifies the integration and purpose.
- Select the intended user and choose Read, Write or Read/Write according to the approved requirement.
- Generate the credentials and copy them once into the integration's secure secret storage.
- Connect over HTTPS using the supported authentication method.
- Test the required operation and confirm that unnecessary operations are not granted.
03 Example: test a WooCommerce reporting key with one product read
Create a dedicated key with Read permission for an approved reporting integration. In its API client, store the consumer key and secret in the protected authentication fields, use HTTPS, and start with a small product request instead of exporting orders or customers.
GET /wp-json/wc/v3/products?per_page=1&_fields=id,name,status HTTP/1.1
Host: store.example.comConfigure the client’s supported Basic authentication using the key and secret; the credential header is intentionally absent from this example. The request asks for at most one product and a narrow set of fields. Core Read permission remains broader than this single endpoint and is also governed by the associated WordPress user’s capabilities.
Expected result: The intended store returns an authorised JSON response, including an empty list if there are no products. Record the key owner, purpose and review date, then revoke the key when the reporting integration ends.
Can I restrict a key to one specific endpoint?
The core key permission choices are broad read/write modes combined with the associated user's capabilities. They are not a complete per-endpoint permission policy. If an integration requires narrower data access, evaluate its architecture and a supported capability or proxy design rather than assuming the description field limits the key.
Where should the secret be stored?
Use the receiving application's protected credential store or an approved secret manager. Do not embed it in public JavaScript, a downloadable file, a screenshot or an ordinary support message. Avoid placing credentials in URLs that can be captured in logs or browser history.
04 Verify and document
Check that the integration reaches the intended store and environment. Record the key's owner, purpose, permissions and review date without copying the secret into the inventory. Test on staging when writes could change products or orders, using separate credentials.
05 Plan revocation
Revoke the key when the integration ends, the owner changes or exposure is suspected. Removing an application from a vendor dashboard may not automatically remove its WooCommerce key. Review associated webhooks and user access as separate parts of the same offboarding task.