Revoke unused WooCommerce API keys so former integrations cannot continue reading or changing store data. Identify the correct key and coordinate the shutdown so a legitimate replacement integration is not interrupted unexpectedly.
IN THIS ARTICLE
01 Identify the credential and dependencies
Review the API key description, associated user and recorded integration owner. Check whether the same credential was reused by more than one application, even though separate keys are preferable. Record scheduled imports, stock synchronisation and order exports that depend on the connection.
02 Revoke access deliberately
- Confirm the integration's end date or complete the replacement connection first.
- Pause its scheduled jobs so failures do not create unnecessary retries or alerts.
- Open WooCommerce > Settings > Advanced > REST API.
- Select the verified key and use the revoke or delete action provided.
- Confirm that a request using the old credential is rejected through a controlled test.
- Record the revocation and remove stored copies from the retired application's secret storage.
Does deleting the key remove data already copied elsewhere?
No. Revocation stops future authenticated access with that credential. Data previously exported to the external service needs a separate retention or deletion process with that service. Confirm what records it still holds and who is responsible for them.
Should I delete the associated WordPress user too?
Review the account separately. It may own content or serve another approved purpose. Revoke the specific integration key first, then remove or reduce the user account only after checking its other responsibilities. Also review application passwords or other tokens that could provide independent access.
03 Check outgoing webhooks
An API key and an outgoing webhook are separate mechanisms. A webhook can continue sending customer or order data to a retired endpoint unless it is paused or removed. Review the full integration inventory rather than assuming one revoked key closes every connection.
04 Respond to suspected exposure
If a key was leaked, revoke it promptly, review relevant store and integration activity, and issue a new narrowly scoped credential only where still needed. Do not restore the old secret to fix a failing job. Keep incident evidence private and avoid reproducing the exposed credential in the change record or support request.