I Get "invalid_client" When Connecting Snowflake via OAuth — How Do I Fix It?

Last updated: May 14, 2026

This usually happens when the Workspace ID (account subdomain) in your Gumloop Snowflake credential doesn't match the Snowflake account where the OAuth integration is registered. Correcting it and re-authorizing resolves the issue.

Symptoms

  • You see invalid_client in the error message when trying to connect Snowflake via OAuth.

  • The OAuth authorization page may load, but the connection fails during the token exchange step after you approve it.

  • You may also see invalid_client when an existing Snowflake OAuth connection tries to refresh its token.

Cause

When you connect Snowflake via OAuth in Gumloop, you enter a Workspace ID — this is the Snowflake account identifier (also called the account subdomain). Gumloop uses this value to build the OAuth token URL:

https://{workspace_id}.snowflakecomputing.com/oauth/token-request

If the Workspace ID points to a Snowflake account (or subaccount) where the OAuth integration's OAUTH_CLIENT_ID is not registered, Snowflake rejects the request with invalid_client.

This is especially common in organizations with multiple Snowflake accounts (e.g., separate accounts for production, development, data lake). The OAuth integration is typically registered on one specific account, but it's easy to accidentally enter a different account's identifier.

How to Fix It

Step 1: Find the correct account identifier

Run this SQL in Snowflake (on the account where the OAuth integration was created):

DESC SECURITY INTEGRATION GUMLOOP_OAUTH;

Look at the OAUTH_TOKEN_ENDPOINT value. It will be a URL like:

https://myorg.us-east-2.aws.snowflakecomputing.com/oauth/token-request

The part before .snowflakecomputing.com is your correct account identifier. In this example, it's myorg.us-east-2.aws.

Step 2: Update the Workspace ID in Gumloop

  1. Go to Settings → Apps.

  2. Find your Snowflake credential and remove it.

  3. Re-add the Snowflake credential. When prompted for the Workspace ID, enter the exact value from Step 1.

Important formatting rules for the Workspace ID:

  • Do not include https://

  • Do not include .snowflakecomputing.com

  • Do not include a trailing slash

  • Do include the region and cloud provider if your account uses the legacy format (e.g., myorg.us-east-2.aws)

Step 3: Re-authorize

  1. After saving the updated credential, click Connect or Authorize.

  2. Complete the Snowflake login and approve the permissions.

  3. You should be redirected back to Gumloop with a successful connection.

Other Causes of invalid_client

If the Workspace ID is already correct, check these less common causes:

  • Wrong Client ID or Client Secret — Verify the values in your org's OAuth configuration at Settings → Organization. Run SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('GUMLOOP_OAUTH'); in Snowflake to get the current credentials.

  • Redirect URI mismatch — The OAuth integration in Snowflake must have https://api.gumloop.com/auth/callback as an allowed redirect URI. Run DESC SECURITY INTEGRATION GUMLOOP_OAUTH; and check that OAUTH_REDIRECT_URI matches exactly.

  • IP allowlist blocking Gumloop — If your Snowflake account uses network policies, ensure Gumloop's IP addresses are allowed. Contact support@gumloop.com for the current list.

  • Rotated secret not yet propagated — If you recently rotated the Client Secret in Snowflake, wait a few minutes, then update the secret in Gumloop and try again.

How Do I Know It Worked?

After re-authorizing, your Snowflake credential should appear as Connected in Settings → Apps. Try running a simple query through your agent to confirm data flows correctly.

Still Need Help?

If this didn't resolve your issue, reach out to support at support@gumloop.com. Include the output of DESC SECURITY INTEGRATION GUMLOOP_OAUTH; (from Snowflake) so the team can cross-reference the configuration.

Related Docs