Skip to main content
Your Snowflake warehouse connector fails to authenticate and Snowflake returns:
Depending on which driver reports it, the SQLSTATE may appear as 08004 or 08001. The error code 390144 is the part that matters.

What It Means

390144 is Snowflake’s generic key-pair authentication failure (JWT_TOKEN_INVALID). Snowflake’s own reference describes it only as There is a general issue with the JWT token. The specific causes have their own codes, but the client usually sees only the generic 390144. Snowflake records the specific reason against the failure, which you can look up as shown below.
Mixpanel generates the key pair for you during connector setup and stores the private key encrypted. You never create, convert, or upload a private key, so causes involving key generation — PKCS#1 versus PKCS#8, passphrase-encrypted keys, wrong openssl flags — do not apply to Mixpanel connections.

Find the Real Error Code First

The failure message contains a UUID in square brackets. Snowflake stores the specific reason against that UUID, and reading it turns a generic 390144 into an actionable code. A Snowflake administrator runs:
This requires the MONITOR privilege. Match the result against the table below.

Common Causes

The Account Identifier Contains Periods

Snowflake requires that periods in an account identifier be replaced with hyphens, because periods in an account identifier cause the JWT to be invalid. The connector setup tells you to take the identifier from your Snowflake URL, and some URL forms (for example, legacy account.region.cloud locators) contain periods. If your identifier has periods, try the hyphenated form.

The Account Identifier Is Wrong

The account in the connection must match the account named inside the token. If you copied the identifier from a browser URL, confirm it does not include the snowflakecomputing.com suffix or a trailing path.

The Public Key Was Never Applied

Mixpanel shows you a public key during setup, and it only takes effect once you set it on the Snowflake user (with CREATE USER ... RSA_PUBLIC_KEY= or ALTER USER). If that step was skipped or run against a different user, authentication fails. Check what Snowflake actually has:
Look at RSA_PUBLIC_KEY, RSA_PUBLIC_KEY_FP, and LOGIN_NAME.

The Key Is On the Wrong User

Snowflake requires the client’s user name to match the user’s LOGIN_NAME, not its NAME. These can differ, so enter the LOGIN_NAME as the user in the connector.

How to Fix It

Read the underlying code with SYSTEM$GET_LOGIN_FAILURE_DETAILS and use the table above. Everything else is guesswork without it. Confirm the key is on the right user. Run DESC USER and check that RSA_PUBLIC_KEY_FP is populated and LOGIN_NAME matches what the connector uses. Re-apply the public key Mixpanel gave you, without the PEM delimiters:
Snowflake requires you to “exclude the public key delimiters in the SQL statement” — do not include the -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY----- lines. Setting a key requires either OWNERSHIP on the user or the MODIFY PROGRAMMATIC AUTHENTICATION METHODS privilege:
Check the account identifier for periods, and replace them with hyphens. If the connector still fails after the underlying code checks out, contact support with the failure UUID.