Where to Find Your Salesforce Consumer Key and Secret

If you're connecting an AI agent, backend integration, or CI/CD pipeline to Salesforce, you may need the Consumer Key and Consumer Secret used for OAuth authentication. These credentials are also called the Client ID and Client Secret.

In this guide, we’ll show you where to find them in classic Connected Apps and External Client Apps, how to choose an appropriate OAuth flow, and how to handle the credentials securely.

Key Takeaways

• The Salesforce Consumer Key is the Client ID, while the Consumer Secret is the Client Secret.
• Classic Connected Apps use App Manager, while External Client Apps use External Client App Manager.
• Different OAuth flows require different credentials. Client credentials use the Consumer Key and Secret, while JWT bearer uses a signed JWT.
• Store the Consumer Secret securely, restrict access, and verify that OAuth scopes and Salesforce permissions match the integration's requirements.
• Engini provides one managed execution layer for AI agents across Salesforce, NetSuite, SAP, and other enterprise systems, centralizing connectivity, permissions, monitoring, and auditability.

What Are the Salesforce Consumer Key and Secret?

These credentials identify the client application during supported OAuth exchanges. The access ultimately granted also depends on the selected OAuth flow, application configuration, and Salesforce user permissions. With that said, not every OAuth flow necessarily requires a Consumer Secret.

Salesforce documents OAuth authentication for REST API calls in its official guide to understanding authentication. Here, it’s worth noting that the credentials belong to the app configuration instead of an individual REST request.

Locating Credentials for a Classic Connected App

For a classic Connected App, the credential path is usually as follows:

1. Open "Salesforce Setup".
2. In the "Quick Find" box, search for "App Manager".
3. Open "App Manager" under "Platform Tools".
4. Find the Connected App.
5. Open the row action menu.
6. Select "View".
7. Find the API ("Enable OAuth Settings") area.
8. Click "Manage Consumer Details".
9. Complete identity verification.
10. Copy the Consumer Key and Consumer Secret.

That is the common path when you need to find the Salesforce Connected App Consumer Key. Salesforce also documents the need to use "Manage Consumer Details" before viewing these credentials in its official help article on consumer key and consumer secret access.

A Few Tips to Make Your Connected App Life Easier

• If you opened "Edit" rather than "View", return to "App Manager" and select "View" from the app's row menu. For Connected Apps installed through a managed package, the package publisher may control how the credentials are created or accessed.
• Salesforce may require MFA, an email verification code, or another verification method before revealing the Consumer Secret. Complete the prompt, copy the credentials, and store the secret in an approved secrets manager rather than in source code or an unsecured configuration file.
• For new integrations, Salesforce recommends External Client Apps. Existing Connected Apps remain relevant for established integrations and applications created under the older model.

Retrieving Credentials for an External Client App

For an External Client App (ECA), we recommend starting from the "Salesforce Setup" and using the External Client App Manager. This is also where newer Salesforce OAuth client configurations live when your organization (org) uses the ECA model.

When dealing with an ECA, make sure to follow these steps:

1. Open "Salesforce Setup".
2. Search for External Client App Manager in the "Quick Find" box.
3. Open "External Client App Manager".
4. Locate your External Client App and open its actions menu.
5. Select "Edit Settings".
6. Open the "OAuth Settings" section.
7. Locate Consumer Key and Secret.
8. Complete identity verification if Salesforce requests it.
9. Copy the available credentials and store the Consumer Secret securely.

Note: Salesforce's interface can vary depending on your organization’s configuration and permissions. Make sure to confirm these UI labels against the current interface used by the client's Salesforce environment.

A Few Tips to Make Your ECA Life Easier

• Salesforce describes External Client Apps as the newer model for OAuth client configuration in its official External Client Apps documentation. If your admin org shows External Client App options or migration prompts, check this path before assuming the credentials live only inside App Manager.
• If you cannot see the credentials, confirm that you have permission to manage the External Client App and that you're viewing the Salesforce org where the application is configured. Avoid placing secrets in agent prompts, notebooks, source code, or shared configuration files.

Comparing Connected Apps vs. External Client Apps

Connected Apps and External Client Apps both support OAuth client configuration, but they reflect different Salesforce app models. If you’re wondering where you should look first when you need a Salesforce Consumer Key, simply reference the table below.

Tip: Use External Client App Manager when the OAuth client was created as an External Client App. Use App Manager for an existing classic Connected App, including older integrations and applicable managed package configurations.

Which OAuth Flow Should Your Integration Use?

Salesforce supports several OAuth flows, and the correct choice depends on whether you need to authorize access, how the application runs, and which credentials your security team permits.

For automated integrations, two important options are the client credentials flow and JWT bearer flow. Both can support non-interactive authentication, but they use different credentials.

Salesforce documents browser-based authentication in its OAuth 2.0 web server flow guide and certificate-based authentication in its JWT bearer flow guide.

For a backend service that needs non-interactive Salesforce access, we recommend evaluating the client credentials and JWT bearer flows against your organization's security requirements.

The client credentials flow is particularly relevant when you are looking for a Consumer Key and Consumer Secret because it uses both values. JWT bearer relies on a signed token and associated signing credentials instead.

Note: authentication alone does not determine what the integration can do. Salesforce permissions, OAuth scopes, and the identity under which API requests execute continue to govern access to records and fields.

How to Secure Your Salesforce API Credentials

A Consumer Secret should be treated like any other production credential. Store it securely, restrict access to the applications and people that need it, and avoid exposing it in logs, repositories, or build pipelines.

So, before using Salesforce credentials in a production integration, ensure to check the following:

• Keep the Consumer Secret in an approved secrets manager. Do not include it in source code, agent prompts, notebooks, or shared configuration files.
• Confirm that the Consumer Key belongs to the intended Salesforce org and Connected App or External Client App.
• Verify that the selected OAuth flow matches the application's configuration and that the required credentials or signing certificates are available.
• For flows that use browser redirects, ensure the callback URL matches the registered redirect URI.
• Confirm that OAuth scopes, user permissions, and object- and field-level access match the integration's requirements.
• Follow your organization's rotation policy and update dependent services when credentials change.
• Log authentication failures without exposing access tokens, secrets, or other sensitive information.

Note: If Salesforce returns an authentication error, first check the app configuration, selected OAuth flow, client credentials, and target Salesforce environment. A mismatch between these settings can prevent access even when the Consumer Key has been copied correctly.

Managing AI Agent Access Across Salesforce and Other Systems

Finding your Salesforce credentials is merely one part of connecting an AI agent to enterprise applications as Salesforce already provides OAuth configuration, user permissions, and access controls for its own platform.

The true challenge arises when that same agent needs to also work across Salesforce, NetSuite, SAP, and other systems. Each application introduces its own authentication requirements, permissions, monitoring, and failure handling, so managing those connections independently can unwillingly expand the infrastructure that teams must build and maintain.

Engini's Agent Gateway provides one managed execution layer across these systems. Through its enterprise connectors, agents can access the applications they need without teams having to maintain separate agent-facing integration infrastructure for every connection.

Engini's Agent Policy also adds scoped permissions, guardrails, and auditability to the execution layer – a set of controls that become increasingly important when several agents participate in the same business process. Our guide to multi-agent AI orchestration and enterprise governance explores how permissions, execution visibility, and coordination affect these workflows.

For agentic workflows involving multiple applications, Engini also helps manage execution and visibility across the systems involved. Teams can now review recorded actions and investigate failed writes, including replaying a failed write when the workflow supports it.

Connecting Salesforce With Your Other Enterprise Systems

Finding your Salesforce Consumer Key and Consumer Secret depends on whether your integration uses a classic Connected App or an External Client App. Once you have the necessary credentials, the next step is choosing the appropriate OAuth flow, securing access, and confirming that the integration has the permissions it needs.

However, if you’re fond of using AI agents operating across multiple enterprise systems, authentication should be only one part of your setup. After all, each additional application introduces its own connection, permissions, monitoring, and operational requirements.

Engini brings that agent-facing infrastructure together in one managed execution layer across Salesforce, NetSuite, SAP, and other enterprise applications. Give your agents governed access to enterprise applications today without maintaining separate execution infrastructure for every system.

Frequently Asked Questions

Can I regenerate a Salesforce Consumer Key and Secret?

Yes. Salesforce allows administrators to rotate the Consumer Key and Consumer Secret for a Connected App. To do this, generate the replacement credentials, update any integrations that depend on them, and coordinate the change to avoid unexpected authentication failures.

Note that applying the new credentials also revokes existing access and refresh tokens, so plan the rotation carefully.

Why is Salesforce rejecting my Consumer Key and Secret?

Authentication failures can occur even when both credentials are correct. Common causes include using the wrong Salesforce environment, selecting an OAuth flow that isn't enabled for the app, or having an incorrect client configuration.

A few possible fixes include checking the authentication error response, verifying the token endpoint, and confirming that the app's OAuth settings match the flow your integration uses.

Can I use the same Consumer Key and Secret in sandbox and production?

The same credentials and configuration may not work in both environments. Salesforce sandboxes have separate authentication environments, and some Connected App OAuth settings may need to be reviewed after a sandbox refresh.

Should multiple AI agents share the same Salesforce credentials?

Sharing credentials can simplify initial setup, but it can also make it harder to separate access, monitor activity, and rotate credentials without affecting other integrations.

Where agents have different responsibilities, consider separate application identities or appropriately scoped access configurations. For agents working across Salesforce and other enterprise systems, a managed execution layer can help centralize connection management and enforce agent-specific policies.