Questions on Snowflake Integration: Authentication and Testing Issues

A few questions on the Snowflake integration:

1.
Is keypair authentication supported? Or is user/pass the only option?
2.
If providing an SSO url, what does Clay expect in the required password field?
3.
Is there a recommended way to test the connection?

I've been attempting to connect and send a few sample rows using my personal Snowflake user, but I'm getting slightly vague error messages like "missing auth." I've reviewed the docs here, but no luck. Thanks!

9 comments

Clay
APP
·
·
Our Snowflake integration documentation shows the authentication process involves clicking "+ Add account" and going through authentication, with specific mention that if your organization uses Okta, you should enter your Okta URL (e.g., example.okta.com) to ensure the integration functions correctly. The documentation doesn't specify details about keypair authentication support or password field requirements for SSO URLs. For testing connections, you can use the Lookup Row action which allows you to run SQL queries to verify connectivity and data access. What specific error message are you seeing when you attempt to connect, and are you using an Okta SSO setup for your Snowflake account?
Sources: Snowflake integration | Documentation | Clay University Lookup Row with Snowflake Insert Row with Snowflake Update Row with Snowflake Upsert Row with Snowflake
Seth G.
·
·
One of the potential issues might be related to connecting from an unknown ip address. We may need to add Clay's IP to our allowed list
Luca P.
·
·
Hey there! Happy to help with your Snowflake integration questions! 🙂 Based on our documentation and recent implementations, here are the answers to your questions: 1. Authentication Options Yes, keypair authentication is supported! Clay offers multiple authentication methods: ** Key Pair Authentication - This is actually the recommended approach for SOC 2 compliant organizations as it's more secure than username/password ** Classic Authentication - Username and password combination ** SSO Authentication - If you're using Okta or similar SSO providers *2. SSO URL and Password Field When providing an SSO URL (like your Okta endpoint), you would enter something like [https://yourcompany.okta.com](https://yourcompany.okta.com) in the Native SSO URL field. [6,7] The password field would still be required - this would be your actual Snowflake user password, even when using SSO authentication.
3. Testing the Connection Here's the recommended approach for testing: 1. Check your Snowflake permissions first by running these queries in Snowflake: SHOW ROLES; SHOW WAREHOUSES; SHOW DATABASES; 2. Critical check: If you only see information_schema when running SHOW SCHEMAS, you don't have the necessary access to the data. 3. Create a dedicated Clay user - Many companies create a sub-user account specifically for Clay with restricted permissions to the tables you want to access. Troubleshooting "Missing Auth" Error The "missing auth" error you're seeing is pretty common. Here are a few things to check: ** Verify your account identifier format (should look like NHDCQCP-SBB20777 or similar) ** Ensure your user has the proper role assignments in Snowflake ** If using SSO, make sure the Okta URL is correctly formatted ** Double-check that your IP is allowlisted if your Snowflake instance has IP restrictions Let me know if this helps and if you have any other questions
Seth G.
·
·
Thanks!
Yes, keypair authentication is supported! Clay offers multiple authentication methods: * Key Pair Authentication - This is actually the recommended approach for SOC 2 compliant
Great, I believe this is typically our preference too. Can you share instructions on this? I didn't find them in the docs.
Double-check that your IP is allowlisted if your Snowflake instance has IP restrictions
Since this is a hosted solution, we would need Clay's IP addresses added to our Snowflake account's allowed list, right? This is what we've had to do for other tools we integrate with Snowflake (example)
Luca P.
·
·
I apologize for the confusion in my previous response! I should have mentioned upfront that the static IP feature for Snowflake is only available on our Enterprise plan. Since you mentioned needing Clay's IP addresses allowlisted for your Snowflake instance (which is a common requirement for enterprise security policies), the static IP functionality would indeed be the solution you're looking for. If you'd be interested in exploring an upgrade to our Enterprise plan to access this feature, I'd be happy to help connect you with the right person to discuss pricing and implementation. The Enterprise plan includes not only the static IP functionality but also other features that are typically valuable for organizations with more stringent security and compliance requirements. For now, without the static IP feature, Clay's outbound requests come from dynamic IP addresses that can change, which unfortunately won't work with IP allowlisting requirements. Would you like me to put you in touch with someone who can walk you through the Enterprise plan options and see if it makes sense for your use case? Thanks again for your patience, and sorry for not catching this important detail initially!
Seth G.
·
·
I believe we're on an enterprise plan currently. Shall I pick this up with our CSM?
Luca P.
·
·
Hi Seth, I would pick up this issue with your CSM. They can assist you with setting this all up!
Seth G.
·
·
Awesome, thanks for the guidance!
Luca P.
·
·
No problem, I'll go ahead and close out this ticket now, but don't hesitate to reach out again if you need any help in the future.
🫡1

02 Support

Questions on Snowflake Integration: Authentication and Testing Issues

Seth G.

A few questions on the Snowflake integration:

1.
Is keypair authentication supported? Or is user/pass the only option?
2.
If providing an SSO url, what does Clay expect in the required password field?
3.
Is there a recommended way to test the connection?

9 comments

Clay
APP
·
·
Our Snowflake integration documentation shows the authentication process involves clicking "+ Add account" and going through authentication, with specific mention that if your organization uses Okta, you should enter your Okta URL (e.g., example.okta.com) to ensure the integration functions correctly. The documentation doesn't specify details about keypair authentication support or password field requirements for SSO URLs. For testing connections, you can use the Lookup Row action which allows you to run SQL queries to verify connectivity and data access. What specific error message are you seeing when you attempt to connect, and are you using an Okta SSO setup for your Snowflake account?
Sources: Snowflake integration | Documentation | Clay University Lookup Row with Snowflake Insert Row with Snowflake Update Row with Snowflake Upsert Row with Snowflake
Seth G.
·
·
One of the potential issues might be related to connecting from an unknown ip address. We may need to add Clay's IP to our allowed list
Luca P.
·
·
Hey there! Happy to help with your Snowflake integration questions! 🙂 Based on our documentation and recent implementations, here are the answers to your questions: 1. Authentication Options Yes, keypair authentication is supported! Clay offers multiple authentication methods: ** Key Pair Authentication - This is actually the recommended approach for SOC 2 compliant organizations as it's more secure than username/password ** Classic Authentication - Username and password combination ** SSO Authentication - If you're using Okta or similar SSO providers *2. SSO URL and Password Field When providing an SSO URL (like your Okta endpoint), you would enter something like [https://yourcompany.okta.com](https://yourcompany.okta.com) in the Native SSO URL field. [6,7] The password field would still be required - this would be your actual Snowflake user password, even when using SSO authentication.
3. Testing the Connection Here's the recommended approach for testing: 1. Check your Snowflake permissions first by running these queries in Snowflake: SHOW ROLES; SHOW WAREHOUSES; SHOW DATABASES; 2. Critical check: If you only see information_schema when running SHOW SCHEMAS, you don't have the necessary access to the data. 3. Create a dedicated Clay user - Many companies create a sub-user account specifically for Clay with restricted permissions to the tables you want to access. Troubleshooting "Missing Auth" Error The "missing auth" error you're seeing is pretty common. Here are a few things to check: ** Verify your account identifier format (should look like NHDCQCP-SBB20777 or similar) ** Ensure your user has the proper role assignments in Snowflake ** If using SSO, make sure the Okta URL is correctly formatted ** Double-check that your IP is allowlisted if your Snowflake instance has IP restrictions Let me know if this helps and if you have any other questions
Seth G.
·
·
Thanks!
Yes, keypair authentication is supported! Clay offers multiple authentication methods: * Key Pair Authentication - This is actually the recommended approach for SOC 2 compliant
Great, I believe this is typically our preference too. Can you share instructions on this? I didn't find them in the docs.
Double-check that your IP is allowlisted if your Snowflake instance has IP restrictions
Since this is a hosted solution, we would need Clay's IP addresses added to our Snowflake account's allowed list, right? This is what we've had to do for other tools we integrate with Snowflake (example)
Luca P.
·
·
I apologize for the confusion in my previous response! I should have mentioned upfront that the static IP feature for Snowflake is only available on our Enterprise plan. Since you mentioned needing Clay's IP addresses allowlisted for your Snowflake instance (which is a common requirement for enterprise security policies), the static IP functionality would indeed be the solution you're looking for. If you'd be interested in exploring an upgrade to our Enterprise plan to access this feature, I'd be happy to help connect you with the right person to discuss pricing and implementation. The Enterprise plan includes not only the static IP functionality but also other features that are typically valuable for organizations with more stringent security and compliance requirements. For now, without the static IP feature, Clay's outbound requests come from dynamic IP addresses that can change, which unfortunately won't work with IP allowlisting requirements. Would you like me to put you in touch with someone who can walk you through the Enterprise plan options and see if it makes sense for your use case? Thanks again for your patience, and sorry for not catching this important detail initially!
Seth G.
·
·
I believe we're on an enterprise plan currently. Shall I pick this up with our CSM?
Luca P.
·
·
Hi Seth, I would pick up this issue with your CSM. They can assist you with setting this all up!
Seth G.
·
·
Awesome, thanks for the guidance!
Luca P.
·
·
No problem, I'll go ahead and close out this ticket now, but don't hesitate to reach out again if you need any help in the future.
🫡1