Hello all, newbie here. I'm refreshing the secret key for our installed Package, Email Concierge API, in Salesforce Marketing Cloud. A consultant initially set up this package, and I was wondering how I can find all the External Apps and Integration using the current secret key, so they can be updated with the newly generated key. What's the easiest way to do this?
#Salesforce Admin #Marketing Cloud Engagement #Marketing Cloud #API
I found suggests Marketing Cloud has a "where used" report for an installed package's secret, so I couldn't confirm a one-click way to list every consumer. I'd verify that with Salesforce Support if it matters. In practice this is an inventory exercise plus a safer cutover.
Where to look for consumers of the credentials
- The package itself (Setup → Apps → Installed Packages). The client ID and secret sit under the component details of the package. The package's scopes (for example email_send or list_and_subscribers_write) hint at what the integration does. Also check whether it's a legacy or enhanced package: packages created after August 1, 2019 are enhanced, while older ones are legacy and use endpoints like v1/requestToken. That tells you which auth calls to search for. salesforce salesforce
- Your Salesforce CRM org, if it connects to Marketing Cloud. Check Named Credentials and External Credentials, Custom Settings and Custom Metadata, and Remote Site Settings. Grep Apex and Flows for auth.marketingcloudapis.com, /v2/token and the client ID. Anything found here is a consumer.
- Inside Marketing Cloud. Search Automation Studio Script activities, CloudPages and Code Resources for the client ID. SSJS and AMPscript sometimes hardcode credentials.
- Outside both platforms. This is where most consumers hide, and only people or config can reveal them:
- middleware or iPaaS (MuleSoft, Zapier, Workato, Boomi)
- the website or app backend, cloud functions and cron jobs
- CI/CD secrets, password managers and Postman collections
- the original consultant, who is your best source. Ask for a list of every system they wired to this package.
- Audit Trail shows who created or changed the package, which can point you to the right people. It doesn't show which systems use it.
Safer than a hard reset: cut over in parallelI couldn't confirm from the docs whether the old secret stops working the instant a new one is generated, so assume it does. Otherwise, any consumer you missed fails at once. A lower-risk approach:
- Create a second package with the same scopes and a new client ID and secret.
- Move integrations to it one at a time, testing each.
- Leave the old package alone for a while and watch for anyone who complains or for failed sends.
- Delete or retire the old package once nothing breaks.
If you must reset the secret on the existing package, do it in a low-traffic window with the consultant and integration owners on standby. Expect invalid_client or 401 errors
from anything you missed.
I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.