salesforce oauth invalid_client_id connected app setup failed

Fix Salesforce OAuth invalidclientid on connected app setup

TL;DR

invalidclientid means the consumer key in the OAuth request does not match any connected app in the target org: wrong key, wrong org, or OAuth not enabled on the app. Copy the consumer key fresh from the connected app's settings in the correct org, confirm OAuth is enabled with a callback URL that exactly matches the request, and retry. Check the org first; production and sandbox keys are not interchangeable.

The error

POST https://login.salesforce.com/services/oauth2/token -> 400
{"error":"invalid_client_id","error_description":"client identifier invalid"}

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=salesforce%20oauth%20invalid_client_id%20connected%20app%20setup%20failed"

Fix it

Step 1: Copy the consumer key from the right org

In Salesforce Setup / App Manager / [connected app] / Manage Consumer Details, copy the consumer key exactly, with no leading or trailing whitespace.

Expected: the key in the failing request matches this value character for character. Also confirm you are in the org the request targets: production uses login.salesforce.com, sandboxes use test.salesforce.com.

Step 2: Confirm OAuth is enabled on the connected app

In the connected app settings, verify "Enable OAuth Settings" is checked.

Expected: enabled. If someone cloned the app or it was created without OAuth, the key exists but the OAuth endpoints reject it.

Step 3: Match the callback URL exactly

Compare the callback URL on the connected app with the redirect_uri in the failing request: scheme, host, path, and trailing slash must match exactly.

Expected: exact match. Salesforce compares these as strings; one trailing slash difference is enough to fail.

Step 4: Check permitted users and approval

Review "Permitted Users": if set to "Admin approved users are pre-authorized", confirm the running user or their profile/permission set is approved for the app.

Expected: the user is authorized. Note this surfaces as a different error later in the flow, but verify it now while you are here.

Step 5: Retry the OAuth flow

Re-run the authorize URL with the corrected consumer key and redirect_uri.

Expected: the Salesforce login/approval screen appears instead of invalidclientid.

When this applies

• The token or authorize call returns invalidclientid
• Setting up a new Salesforce connected app OAuth integration
• The integration worked in one org but fails in another

When it doesn't

• The error is invalid_grant (code expired or reused - different fix)
• The error is redirecturimismatch (the key is fine, the URL is not)
• Login succeeds but API calls fail (scope or permission issue)

Compatibility

Salesforce connected apps, OAuth 2.0 web server and user-agent flows. Applies to production and sandbox orgs.

Variant phrasings

salesforce connected app client identifier invalid

Same error. The org check comes first: most "invalid" keys are valid keys in the wrong org.

oauth invalidclientid salesforce sandbox

Sandbox refreshes wipe connected app config. After a sandbox refresh, re-verify the app exists there.

Why it happens

Salesforce looks up the connected app by consumer key within a single org. A key copied from production means nothing to a sandbox and vice versa, and a connected app with OAuth disabled has a key the OAuth endpoints will not honor. Any of these looks like a wrong key.

Edge cases

• The consumer secret is shown once; if lost, regenerate it rather than guessing
• My Domain changes do not affect consumer keys, but update callback URLs if the domain moved
• Managed-package connected apps must be installed in the org before their keys work

If it still fails

• Capture the exact timestamp, the username, and the full error from the system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• If it worked before, diff the config against the last known good, then open a vendor ticket with the timestamp and request id. Never send secrets or private keys.

Prevention

• Track credential and certificate expiry with alerts, not memory.
• Run a synthetic check per app daily so breakage pages you, not a user.
• Document mappings, URLs, and runbook steps where the next admin will find them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pIbqTqq4ngryiFIVtOM-3w