In Snowflake, integrations are native objects that enable seamless connectivity with external services. Snowflake supports six distinct integration types, allowing seamless connectivity with third-party applications and cloud services. With Snowflake integrations, you can unlock powerful capabilities, including:

• Seamless API connectivity — Connect to Git, cloud service APIs, and external platforms.
• Hybrid storage solutions — Combine Snowflake’s performance with external storage options.
• API-powered operations — Use APIs as resources to enhance data processing and workflows.
• Smart notifications — Integrate with email, Slack, webhooks, and cloud messaging services.
• Robust security — Implement authentication integrations for secure access.
• Flexible data storage — Leverage cloud services for inbound and outbound data management.

Integrations, like other Snowflake objects, can be altered, recreated, or dropped. Once an integration is dropped, it cannot be recovered, it can only be re-created, making careful management essential .

To create an integration, you need the “CREATE INTEGRATION” privilege on your role. By default, only the ACCOUNTADMIN role has this permission. However, for better security, you can assign this privilege to custom roles, reducing reliance on ACCOUNTADMIN for integration management.

For maintenance, integrations can be temporarily disabled by setting the ENABLED parameter to FALSE. Since integrations may be cached, disabling or dropping an integration might not take effect immediately. In such cases, removing integration privileges ensures that access is fully revoked.

Now, let’s explore the six types of Snowflake integrations and how they can elevate your data operations.

EXTERNAL ACCESS INTEGRATION

External access integration in Snowflake allows you to call an API directly from a function or handler. This enables you to either leverage the API’s functionality or retrieve and parse JSON data from the response.

Since this integration accesses an external API, you can enhance security by creating a network rule and a secret object for authentication, passing them as parameters within the integration.

Best practices and considirations;

• Handle transient errors — Expect occasional failures and implement retries where necessary.
• Process one row at a time — This ensures deterministic results and prevents inconsistencies.
• Optimize network usage — Use a single TCP connection instead of multiple ones to avoid bottlenecks.

API INTEGRATION

At first glance, API integration may sound similar to external access integration, but it serves a different purpose. This integration is specifically designed to connect Git, AWS, Google Cloud, and Azure HTTPS-based APIs directly from Snowflake.

API integrations in Snowflake are designed for use within external functions. With API integration, you can securely interact with cloud services while maintaining control over access. You can allow or restrict specific endpoints, ensuring only approved services are accessible.

Key considirations;

• Modifying Integrations — You can alter an existing integration, but you cannot change the API provider (API_PROVIDER parameter) once it’s set.
• Secure Access Control — Manage access by defining allowed and removed endpoints.
• API integrations in Snowflake are tied to a specific cloud account, not an HTTPS proxy URL. This means that if you need to access the same HTTPS endpoint from multiple cloud accounts, you must create a separate API integration for each account.

CATALOG INTEGRATION

Catalog integration enables you to combine Snowflake’s performance and query semantics with external cloud storage by creating Apache Iceberg tables. This allows you to work with large-scale data lakes without storing the data directly in Snowflake. You can create catalog integrations with the following services, using them as metadata catalogs for Apache Iceberg tables:

• AWS Glue
• Object Storage
• Apache Iceberg REST
• Snowflake Open Catalog

In essence, catalog integration bridges the gap between data lakes and Snowflake. In this way, the functionalities below offered by Snowflake, which are not available in data lakes, are utilized.

• Query external data without ingestion — No need to move data into Snowflake’s internal storage.
• Leverage ACID transactions — Maintain data integrity and consistency.
• Enable high-performance queries — Benefit from Snowflake’s query engine while working with external data.
• Support time travel — Perform historical queries, a feature standard data lakes don’t typically offer.

When working with catalog integration and Apache tables in Snowflake, there are several important aspects to keep in mind:

• External Volume Setup: Ensure that the external volume pointing to your storage is properly created.
• Trust Relationships: Establish necessary trust configurations, such as AWS IAM roles or authentication definitions.
• Refresh Intervals: Adjust the refresh intervals to keep metadata updates in sync.
• Integration Management: You cannot drop or recreate an integration if it has existing Apache tables attached. To check the associated tables, use:

SHOW APACHE TABLES; 

SECURITY INTEGRATION

Security integrations in Snowflake enable external authentication through various third-party applications, ensuring secure and seamless access. There are five types of security integrations, each serving different authentication needs.

1- API Authentication:

Supports two authentication types:

• AWS IAM (AWS_IAM) → Uses AWS IAM roles to authenticate with AWS services.
• OAuth2 (EXTERNAL_OAUTH) → Allows authentication to external APIs using OAuth tokens.

2- External Oauth:

Enables clients to use third-party authorization servers for logging into Snowflake. Supported providers include:

• OKTA
• Azure AD
• Ping Federate
• Custom

For security enhancements you can define RSA keys and restrict authentication to specific Snowflake roles for better security control.

3- Snowflake Oauth:

Used for third-party authorization servers to authenticate into Snowflake from custom or partner applications. Supported auth_clients are:

• TABLEAU_SERVER
• TABLEAU_DESKTOP
• LOOKER
• CUSTOM (When connecting Snowflake to Tableau using private connectivity, you must use the CUSTOM auth client instead of predefined options like TABLEAU_SERVER or TABLEAU_DESKTOP)

Similar to External OAuth, you can restrict authentication to specific Snowflake roles for added security.

4- SAML2 (Security Assertion Markup Language 2.0):

Provides Single Sign-On (SSO) authentication via third-party Identity Providers (IdPs) such as:

• Okta
• Custom IdPs
• Active Directory Federation Services (ADFS)

As a setup requirement, the SAML2_X509_CERT parameter must be configured with the certificate obtained from the SAML2 provider.

5- SCIM (System for Cross-domain Identity Management):

SCIM is an SSO-based authentication method similar to SAML2 but with automated user and role management. This makes SCIM more efficient for provisioning users and roles directly in Snowflake. Supported SCIM providers are:

• Azure AD (AAD_PROVISIONER)
• Okta (OKTA_PROVISIONER)
• Generic (GENERIC_SCIM_PROVISIONER)

Unlike SAML2, SCIM can import and manage users & roles from identity provider server, making it a more scalable and automated solution.

STORAGE INTEGRATION

Storage integrations in Snowflake store the address and access credentials for external cloud storage, eliminating the need for manual login operations. This simplifies authentication and enhances efficiency when working with cloud-based data. Storage integrations also provide security enhancements by implementing;

• Location-based restrictions to block unauthorized access
• Private endpoints for secure communication
• Virtual private environments (VPEs) for isolated network access

Important: If your Snowflake account is not hosted on the same cloud provider as your external storage, you cannot use a virtual private environment — your storage must be public in this case.

Key points for storage integrations are;

• Reconfiguration After Changes: If you drop or recreate a storage integration, all associated objects disappear, requiring reconfiguration.
• Cross-Cloud and Cross-Region Costs: If your external storage is in a different cloud provider or a different region within the same provider, outbound data transfer charges may apply.
• Regulatory Restrictions: Certain regions, such as government cloud environments and countries like China, impose restrictions on external storage. Snowflake does not support storage integrations in these regions.

NOTIFICATION INTEGRATION

Snowflake provides several notification integration options to streamline event-based messaging across different platforms. Here’s a breakdown of the available notification types:

1- Queue- Based Notifications:

Used for sending inbound and outbound event notifications to AWS, Azure, and Google Cloud. Supported queue providers include:

• AZURE_STORAGE_QUEUE → Azure Event Grid Topic
• AWS_SNS → Amazon SNS Topic
• GCP_PUBSUB → Google Cloud Pub/Sub

Key Considerations:

• You can use the same notification integration for multiple outbound push notifications.
• You cannot use the same integration for multiple inbound notifications.
• Outbound notifications are only supported for the cloud provider where your Snowflake account is hosted

Security and additional insights;

• Private links can enhance security for AZURE_STORAGE_QUEUE and AWS_SNS.
• Government regions cannot receive event notifications from other regions.
• Cloud providers may cache notifications, meaning simply disabling notifications does not always stop them immediately. To fully disable, revoke the necessary privileges on the notification integration.

2- Email Notifications:

Sends email alerts to default and allowed recipients, including Slack channels. This ensures key stakeholders stay informed without requiring cloud-specific setups.

For slack notification integrations see the article : SNOWFLAKE AND SLACK NOTIFICATION INTEGRATION | by Asli Imre | Dec, 2024 | Medium

3- Webhook Notifications:

Delivers notifications to platforms like Microsoft Teams, Slack, and PagerDuty via webhooks.

• Access credentials can be optionally stored in secrets for added security.
• Webhook URLs must be explicitly defined in the configuration.

---

---