Why sandbox logins are supposed to go through test.salesforce.com
Production Salesforce orgs authenticate through login.salesforce.com. Every sandbox type — Developer, Developer Pro, Partial Copy, and Full — is a separate org with its own OAuth endpoint at test.salesforce.com, not a subset of production. This is standard Salesforce platform behavior, not something specific to n8n: any OAuth-based integration pointed at login.salesforce.com for a sandbox org will fail or authenticate against the wrong org entirely.
n8n's Salesforce credential includes an "Environment Type" setting specifically so it can send the OAuth authorization request to the correct endpoint (test.salesforce.com for Sandbox, login.salesforce.com for Production). A user on n8n Cloud reported that with Environment Type correctly set to Sandbox, the popup still opened login.salesforce.com for a Developer-license sandbox — while the same instance and credential type connected without issue to a Partial Copy sandbox. That's a strong signal the Sandbox setting isn't being honored consistently for every sandbox license type, rather than anything wrong with how the credential was filled in.
Confirm you're looking at this exact pattern before troubleshooting further
Before assuming this is the same open bug, rule out the more common causes covered elsewhere on this site: an incorrect redirect URI in the Connected App, or Connected App OAuth policy settings (scopes, PKCE, Permitted Users) misconfigured for your app type. Those produce different, more specific error text — a redirect_uri_mismatch message, or a generic OAUTH_APPROVAL_ERROR_GENERIC after Salesforce has already accepted the app. This particular bug is narrower: the popup opens the wrong domain (login.salesforce.com) before you even reach a login form, specifically for a Developer sandbox, with Environment Type already set correctly to Sandbox.
If you can log into the same sandbox manually in a browser — going to the sandbox's own login page directly rather than through n8n — and that works fine through test.salesforce.com, but n8n's OAuth popup still opens login.salesforce.com, that confirms the problem is in how n8n resolves the login host for this credential, not in the sandbox itself.
- Redirect URI is confirmed correct in the Connected App and matches n8n's generated OAuth Redirect URL exactly.
- Environment Type in the n8n credential is set to Sandbox, not Production.
- The same n8n instance and credential type connects successfully to a Partial Copy or Full sandbox — isolating the failure to the Developer license specifically.
- Manually logging into the sandbox in a browser (outside of n8n) works normally through test.salesforce.com.
What to actually do about it right now
There is no confirmed fix published for this specific bug as of this writing. The practical options, in order of effort:
First, check your n8n version against the Community thread's reported version (n8n Cloud 1.121.3) and against n8n's release notes for any Salesforce-credential fix mentioned after that version — if you're on a materially newer release and haven't retested, do that before anything else. Second, if a Developer sandbox isn't a hard requirement for what you're testing, use a Partial Copy or Full sandbox instead, since those are reported to connect normally. Third, if you depend specifically on a Developer sandbox, file (or add a reply/vote to) the existing Community report so it stays visible to n8n's maintainers, rather than opening a fresh duplicate thread that fragments the report.
Sources checked for this guide
The Production vs Sandbox OAuth endpoint distinction (login.salesforce.com vs test.salesforce.com) is standard, documented Salesforce OAuth behavior referenced in n8n's Salesforce credentials documentation. The specific Developer-license sandbox failure pattern, the n8n Cloud version it was reported on, and the fact that it remains unresolved with no staff response come directly from the original report on the n8n Community forum — nothing in this guide claims a fix beyond what that thread actually confirms.