# Fix Salesforce OAuth invalid_client_id on connected app setup

## TL;DR
invalid_client_id 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
```text
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:
```bash
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

```bash
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

```bash
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

```bash
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

```bash
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

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

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

## When this applies

- The token or authorize call returns invalid_client_id
- 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 redirect_uri_mismatch (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 invalid_client_id 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