Know which user and integration a WooCommerce API key belongs to

Find the key record without copying its secret

WooCommerce documents REST API key management under WooCommerce, Settings, Advanced, REST API. Record the site, a non-secret reference that distinguishes the key, its associated WordPress user and its listed permission. Keep the credential itself in the approved credential system. A key label can help locate the entry, but a descriptive name alone does not establish which integration currently consumes it.

The consumer secret is shown once when the key is created. A handoff inventory is therefore not a request to reveal or paste that secret. Do not regenerate or revoke a key merely because the new staff member cannot see the original secret in the settings screen. First identify how the legitimate consumer is configured and who is authorized to manage it.

Keep the site context with every key reference. An integration name without the WooCommerce site it connects to is too ambiguous to support a change decision.

Connect the WordPress user to the real consumer

The associated WordPress user and the person responsible for an integration are different entries in the handoff. A departing employee may be the user named on a key while a separate service continues consuming it. Conversely, a service name in a key description does not prove the service still runs. Use the integration’s authorized configuration records and the actual maintenance handoff to establish the relationship.

Ask the current owner to identify the application or service that uses the key, the task it performs and the location of its controlled configuration. Record locations and references rather than credentials or customer payloads. Available dated activity can support that the dependency is active; a missing recent log cannot establish that an occasional or scheduled task has been retired.

If no one can identify the consumer, mark the dependency unknown and name the person responsible for resolving it before the planned handoff. Do not rename that uncertainty as unused access. This inventory supports a continuity decision; it is not permission to retain access indefinitely.

Compare permissions with the task being handed over

WooCommerce offers Read, Write and Read/Write permissions for REST API keys. Preserve the actual setting and describe what the integration really needs to do. Separate a task that retrieves store records from one that changes them; do not treat all integrations as needing the broadest permission.

A permission label alone is not a complete statement of effective access or every endpoint the application needs. If the task and setting appear inconsistent, the authorized maintainer should reconcile them with the installed integration before anyone changes the permission. Record the mismatch as a specific question instead of broadening access by default.

For a proposed user removal, list all known keys associated with that user and map their consumers before the change is authorized. This page does not assert a universal deletion cascade, automatic reassignment or credential migration procedure. Those behaviors must be established for the actual site and change.

Make continuity evidence part of the authorized change

For an active consumer, name who authorizes the change, who controls the integration configuration and who will confirm its required behavior afterward. If the handoff needs a replacement credential, agree on its associated user, required permission and secure delivery route with those owners. Do not assume that creating a new key updates the consuming application.

The evidence of continuity is the intended integration task working through the authorized configuration after the change. Use genuine operational activity and the relevant system records; do not create customer orders or replay writes solely to make a completion record. When the task has not yet run, preserve that limitation and the person responsible for checking its next legitimate execution.

Once the business has confirmed that a key has no remaining authorized consumer, it can include revocation in its approved retirement steps. A successful replacement task does not automatically prove that every dependency on the former key is gone. Keep the completed consumer inventory with the authorization rather than relying on memory.

For a Prism checkout-review consultation, describe the website, research-only products and the dependency you need help clarifying. Confirm whether the requested handoff or implementation work fits the agreed scope, responsibilities, fees and terms. Do not send keys, passwords or customer records through the public form; the inquiry receives email follow-up and does not purchase a change.

Integration credential dependency

Use one copy per key and consumer relationship. Fill the final column with non-secret references and authorized record locations. An unknown consumer or unobserved post-change task remains an open dependency; it is not evidence that revocation is safe.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.