WooCommerce REST API keys inherit permissions assigned at creation and can read or change orders, products and customers. Revoking them stops future requests but can interrupt ERP, shipping, mobile or automation systems.
Preserve metadata and usage evidence, then replace one integration at a time.
Contain active misuse
If unknown API activity continues, revoke the affected key immediately and pause dependent automation. Preserve key ID/description, user owner, permission level, creation and last-used evidence first when safe.
Do not copy the consumer secret into a ticket or log. If the secret appeared in a public repository/log, treat it as compromised even without observed misuse.
Record revocation time.
Identify every integration
Map ERP, inventory, shipping, accounting, CRM, mobile app and custom automation using WooCommerce API. Confirm owner, endpoints, permissions and expected request patterns.
Do not issue one shared replacement key for all services. One key per named integration makes future revocation and auditing possible.
Retire undocumented clients.
Review activity and scope
Search web/WAF/application logs for authenticated REST routes, methods, timestamps and affected objects tied to the key/user. Avoid logging or exporting customer/order bodies.
Determine what its read/write permissions allowed and what evidence shows occurred. A read/write key exposure does not prove every record was accessed.
Escalate possible data exposure through the authorised incident process.
Secure the parent user
API keys are associated with a WordPress user. Verify that user’s identity, role, email, sessions and application passwords; reset/revoke access as warranted.
Use a dedicated service account with the minimum WooCommerce role/capabilities possible rather than an employee administrator.
Enable MFA for human accounts and protect the owner email.
Reduce permissions and data exposure
Check whether the integration truly needs customer/order Read, catalogue Write or full Read/Write. Split read-only reporting from order/stock mutation where possible.
Limit API responses and logs to necessary fields. Do not give a service administrator privileges simply because its old key had them.
Review custom endpoints that may ignore normal WooCommerce capability checks.
Issue replacement keys
Create a new key for one verified integration with the minimum necessary Read, Write or Read/Write permission. Deliver the secret through an approved secret manager/managed channel.
Do not store keys in theme files, public repositories, browser JavaScript or analytics variables. Restrict network/source where infrastructure supports it.
Label owner and rotation date without storing the value.
Update and validate clients
Change the integration configuration, test a harmless read or sandbox operation, and confirm expected request logs. For write clients, use a controlled synthetic product/order and prevent duplicate side effects.
Check retries and idempotency. A failed client may queue writes and replay them after the key changes.
Remove old secret copies from environment/deployment/backup systems as policy permits.
Revoke and monitor
After the replacement works, revoke the old key and confirm requests using it fail. Alert on attempts with retired credentials and unusual API routes/volume.
Review webhooks, application passwords and payment-provider keys separately; rotating WooCommerce REST credentials does not replace them.
Monitor order/user/product changes during the incident window.
Secure secret storage and deployment
Store new keys in managed environment/secret configuration with restricted access. Remove them from repositories, CI logs, support exports and old staging environments.
If history or backups contain the old secret, revocation protects current access; still remediate public history and restrict backup access. Document where the replacement is allowed to exist.
Reconcile affected data
Compare orders, refunds, users, stock, prices and webhook configuration with authorised business records. Preserve object IDs and audit logs.
Do not bulk reverse changes without understanding accounting/fulfilment effects. Assign owners for each correction.
Request urgent API incident help when the key had write access or its clients are unknown. Share key IDs/descriptions and redacted activity—never secrets, customer exports or credentials publicly.