Skip to main content

Snowflake

Snowflake Integration Guide

Overview

This guide explains how to connect Bridged with Snowflake to enable data warehousing, analytics, and reverse ETL capabilities. The integration supports reading customer data from Snowflake for activation, as well as writing engagement data and conversation outcomes back to Snowflake for unified analytics.

Snowflake is a cloud-based data warehouse that provides a single, integrated platform for data storage, processing, and analytics. It separates storage and compute resources, allowing independent scaling of each. Snowflake supports standard SQL querying and works with all major cloud providers (AWS, Azure, GCP) .

Prerequisites

Before starting, ensure you have:

  • A Snowflake account with appropriate access (trial accounts available)

  • A Snowflake user with warehouse usage permissions and database access

  • For Bridged to read/write data: A dedicated database and schema for Bridged operations

  • Network access: If your Snowflake account has IP allowlisting, add Bridged's IP addresses (contact support for the list)

Connection Methods

Bridged supports three authentication methods for Snowflake:

Method

Best for

Setup complexity

Security Level

Key Pair (Preferred)

Production, server-to-server, automation

Medium

High

Username/Password

Testing, development

Low

Low (deprecated)

Snowflake OAuth

Multi-tenant apps, SSO environments

Medium-High

High

Recommendation: Key Pair authentication is the preferred method for production integrations. Username/password authentication is being deprecated by Snowflake and should be avoided for production use .

Step 1: Prepare Your Snowflake Account

Step 1.1: Create a Dedicated Warehouse for Bridged

For optimal performance and cost control, create a dedicated virtual warehouse for Bridged operations:

sql

CREATE WAREHOUSE bridged_wh
  WAREHOUSE_SIZE = 'SMALL'
  AUTO_SUSPEND = 300
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE
  COMMENT = 'Warehouse for Bridged integration operations';

Step 1.2: Create a Database and Schema

sql

CREATE DATABASE bridged_integration
  COMMENT = 'Database for Bridged data sync operations';

CREATE SCHEMA bridged_integration.bridged_data
  COMMENT = 'Schema for Bridged customer and conversation data';

Step 1.3: Create a Dedicated User for Bridged

sql

CREATE USER bridged_user
  PASSWORD = 'temporary_password'  -- Will use key pair authentication
  DEFAULT_ROLE = 'bridged_role'
  DEFAULT_WAREHOUSE = 'bridged_wh'
  DEFAULT_NAMESPACE = 'bridged_integration.bridged_data'
  MUST_CHANGE_PASSWORD = FALSE
  COMMENT = 'Service account for Bridged integration';

Step 1.4: Create a Role and Grant Permissions

sql

CREATE ROLE bridged_role;

GRANT USAGE ON WAREHOUSE bridged_wh TO ROLE bridged_role;
GRANT USAGE ON DATABASE bridged_integration TO ROLE bridged_role;
GRANT USAGE ON SCHEMA bridged_integration.bridged_data TO ROLE bridged_role;
GRANT CREATE TABLE ON SCHEMA bridged_integration.bridged_data TO ROLE bridged_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA bridged_integration.bridged_data TO ROLE bridged_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON FUTURE TABLES IN SCHEMA bridged_integration.bridged_data TO ROLE bridged_role;

GRANT ROLE bridged_role TO USER bridged_user;

Step 2: Configure Key Pair Authentication (Preferred)

Key pair authentication uses a 2048-bit RSA key pair for secure, passwordless authentication. This is the recommended method for production integrations .

Step 2.1: Generate a Private/Public Key Pair

Using OpenSSL (command line):

bash

# Generate a 2048-bit private key
openssl genrsa -out bridged_private_key.p8 2048

# Generate a corresponding public key
openssl rsa -in bridged_private_key.p8 -pubout -out bridged_public_key.pub

# Generate a private key in PKCS#8 format (required by Snowflake)
openssl pkcs8 -topk8 -inform PEM -in bridged_private_key.p8 -outform PEM -out bridged_private_key_pk8.p8 -nocrypt

Important: Store the private key (bridged_private_key_pk8.p8) securely. You will need to upload its content to Bridged.

Step 2.2: Assign the Public Key to the Snowflake User

sql

ALTER USER bridged_user SET RSA_PUBLIC_KEY = '-----BEGIN PUBLIC KEY-----
<your_public_key_content>
-----END PUBLIC KEY-----';

Step 2.3: Verify Key Pair Authentication

sql

-- Test key pair authentication (run from a machine with the private key)
-- This should connect successfully without a password

Step 2.4: Configure Bridged to Connect Using Key Pair

  1. Log in to your Bridged dashboard.

  2. Navigate to the Integrations section. If you do not see this section, contact support@bridged.media.

  3. Click SnowflakeConnect Account.

  4. Choose Key Pair as your authentication method.

  5. Enter the following credentials:

Field

Description

Where to find

Account

Snowflake account identifier

Format: orgname-accountname (e.g., xy12345-east-2.aws)

Username

Bridged user name

bridged_user (from Step 1.3)

Private Key

Content of private key file

The entire content of bridged_private_key_pk8.p8

Warehouse

Virtual warehouse name

bridged_wh

Database

Database name

bridged_integration

Schema

Schema name

bridged_data

Role (optional)

Snowflake role

bridged_role

Note: The account identifier should not include the full URL. Use the format orgname-accountname .

Step 3: Configure Username/Password Authentication (Development Only)

Warning: Username/password authentication is being deprecated by Snowflake. Use only for testing and development .

  1. In Bridged, navigate to IntegrationsSnowflakeConnect Account.

  2. Choose Username/Password as your authentication method.

  3. Enter the following credentials:

Field

Description

Account

Snowflake account identifier (e.g., xy12345-east-2.aws)

Username

bridged_user

Password

The user's password

Warehouse

bridged_wh

Database

bridged_integration

Schema

bridged_data

Role (optional)

bridged_role

Step 4: Configure Snowflake OAuth (Alternative)

For environments using OAuth (e.g., with Okta or Microsoft Entra ID), Snowflake OAuth provides federated authentication .

Prerequisites for OAuth

  • Snowflake OAuth configured in your Snowflake account

  • OAuth client ID and client secret

  • OAuth authorization endpoint URL

Configure OAuth in Bridged

  1. In Bridged, navigate to IntegrationsSnowflakeConnect Account.

  2. Choose OAuth as your authentication method.

  3. Enter the following:

Field

Description

Account

Snowflake account identifier

Client ID

OAuth client identifier

Client Secret

OAuth client secret

Authorization URL

Your OAuth provider's authorization endpoint

Warehouse

bridged_wh

Database

bridged_integration

Schema

bridged_data

  1. Click Connect with OAuth.

  2. You will be redirected to your identity provider to authenticate.

  3. After authorization, you will be redirected back to Bridged.

Step 5: Configure Sync Settings

Once connected, configure the following:

Setting

Options

Description

Sync direction

Read only, Write only, Read + Write

Define data flow

Operation type

Table sync, Query-based, Both

Table sync copies entire tables; query-based uses custom SQL

Sync frequency

Real-time, Hourly, Daily

How often to sync data

Incremental sync field

Timestamp column (e.g., updated_at)

Only sync changed records since last sync

Batch size

50 records (max)

Number of records per bulk operation

Bulk sync limit: Each bulk operation is limited to 50 records per request.

File Sizing Best Practices

For optimal load performance when syncing large datasets:

Recommendation

Guideline

Optimal file size

100-250 MB compressed

Maximum file size

Avoid files 100 GB or larger

Aggregate small files

Minimize processing overhead

Split large files

Distribute load across warehouse compute resources

Note: Loading very large files (100 GB+) is not recommended. If a load operation exceeds 24 hours, it may be aborted without committing any portion of the file .

Step 6: Reading Data from Snowflake (Bridged → Snowflake)

Bridged reads customer data from Snowflake using standard SQL SELECT queries. This is used for activation playbooks where customer profiles need to be pulled into Bridged for messaging.

Example: Read Customer Profiles for Activation

Bridged executes queries like the following:

sql

SELECT 
    customer_id,
    email,
    phone,
    first_name,
    last_name,
    last_interaction_date,
    lead_score
FROM bridged_integration.bridged_data.customer_profiles
WHERE opt_in_status = 'subscribed'
  AND last_interaction_date > DATEADD(day, -30, CURRENT_DATE())
LIMIT 50;

Incremental Reads

To minimize data transfer and API usage, Bridged supports incremental reads using a timestamp column:

sql

SELECT * FROM bridged_integration.bridged_data.customer_profiles
WHERE updated_at > :last_sync_timestamp
LIMIT 50;

Supported Data Types

Bridged can read all standard Snowflake data types, including:

  • Numeric: NUMBER, INTEGER, FLOAT, DECIMAL

  • String: VARCHAR, CHAR, TEXT

  • Date/Time: DATE, TIME, TIMESTAMP, TIMESTAMP_LTZ, TIMESTAMP_NTZ, TIMESTAMP_TZ

  • Semi-structured: VARIANT (converted to JSON), ARRAY, OBJECT

  • Binary: BINARY (converted to base64)

Note: ARRAY and OBJECT data types have a storage limit of 128 MB .

Step 7: Writing Data to Snowflake (Bridged → Snowflake)

Bridged writes engagement data, conversation transcripts, and lead scores to Snowflake using INSERT and MERGE operations.

Step 7.1: Create Target Tables in Snowflake

Create the tables that will receive data from Bridged:

sql

-- Customer engagement events table
CREATE TABLE IF NOT EXISTS bridged_integration.bridged_data.customer_engagement (
    event_id VARCHAR(100) PRIMARY KEY,
    customer_id VARCHAR(100),
    customer_email VARCHAR(255),
    customer_phone VARCHAR(50),
    event_type VARCHAR(50),
    channel VARCHAR(50),
    conversation_id VARCHAR(100),
    message_content TEXT,
    engagement_timestamp TIMESTAMP_NTZ,
    metadata VARIANT,
    created_at TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP()
);

-- Lead scores table
CREATE TABLE IF NOT EXISTS bridged_integration.bridged_data.lead_scores (
    lead_id VARCHAR(100) PRIMARY KEY,
    score INTEGER,
    score_source VARCHAR(50),
    qualified BOOLEAN,
    qualification_date TIMESTAMP_NTZ,
    last_updated TIMESTAMP_NTZ
);

Step 7.2: Write Data from Bridged

Bridged uses INSERT operations to write data. For existing records, Bridged supports upsert (update or insert) operations:

sql

-- Upsert example (Bridged handles this automatically)
MERGE INTO bridged_integration.bridged_data.lead_scores AS target
USING (SELECT * FROM temp_staging) AS source
ON target.lead_id = source.lead_id
WHEN MATCHED THEN UPDATE SET
    target.score = source.score,
    target.qualified = source.qualified,
    target.last_updated = CURRENT_TIMESTAMP()
WHEN NOT MATCHED THEN INSERT
    (lead_id, score, score_source, qualified, qualification_date, last_updated)
    VALUES (source.lead_id, source.score, source.score_source, source.qualified, source.qualification_date, CURRENT_TIMESTAMP());

Step 8: Test the Integration

  1. In Bridged, go to IntegrationsSnowflakeTest Connection.

  2. Verify that the connection is successful and the warehouse is accessible.

  3. Run a test read query to verify SELECT access.

  4. Create a test record in Snowflake and verify Bridged can read it.

  5. From Bridged, write a test record to Snowflake and verify it appears in the target table.

Testing with SQL

You can verify the integration by running queries directly in Snowflake:

sql

-- Check that Bridged user has correct permissions
SHOW GRANTS TO USER bridged_user;

-- Test write access
INSERT INTO bridged_integration.bridged_data.lead_scores (lead_id, score, qualified)
VALUES ('test_lead_001', 85, FALSE);

-- Verify the insert
SELECT * FROM bridged_integration.bridged_data.lead_scores WHERE lead_id = 'test_lead_001';

Common Use Cases

Playbook

Direction

Description

Activation

Read

Pull customer profiles from Snowflake for WhatsApp/SMS broadcast campaigns

Qualification Agent

Read + Write

Read customer 360 data from Snowflake for lead scoring; write scores back to Snowflake

Nurture & Conversion

Write

Write conversation transcripts and engagement events to Snowflake for analytics

Customer 360

Read

Access unified customer data from Snowflake for personalized agent responses

Reverse ETL

Write

Push qualified leads and engagement data from Snowflake back to operational systems

Rate Limiting & Performance

  • Rate limits are determined by your Snowflake warehouse size and configuration, not by Bridged

  • Concurrent queries: Limited by warehouse compute resources

  • Bulk operations: Maximum 50 records per request

  • Query timeout: Bridged sets a default timeout of 300 seconds (5 minutes)

Performance Optimization Tips

Consideration

Recommendation

Large tables

Use incremental sync with timestamp columns

Frequent syncs

Keep warehouse auto-suspend low (e.g., 60 seconds) to control costs

Complex queries

Create materialized views or pre-aggregated tables

Clustering

Define clustering keys on frequently filtered columns

Batch sizes

Follow Snowflake's recommendation of 100-250 MB compressed files

Security & Permissions

  • Bridged supports Key Pair (preferred), Username/Password, and OAuth authentication

  • Key pair authentication uses 2048-bit RSA encryption

  • All API calls are made over TLS 1.2+

  • Bridged can be restricted to specific warehouses, databases, and schemas via Snowflake roles

  • You can revoke access at any time by:

    • Disabling or deleting the Bridged user

    • Rotating the public key (ALTER USER ... SET RSA_PUBLIC_KEY = 'new_key')

    • Revoking role grants (REVOKE ROLE bridged_role FROM USER bridged_user)

Required Permissions Summary

Permission

Object

Required for

USAGE

Warehouse

Executing queries

USAGE

Database

Accessing the database

USAGE

Schema

Accessing the schema

CREATE TABLE

Schema

Creating new tables (if auto-creation enabled)

SELECT

Tables

Reading data

INSERT

Tables

Writing new records

UPDATE

Tables

Updating existing records

DELETE

Tables

Deleting records (if needed)

Key Rotation Best Practices

Snowflake recommends rotating authentication keys regularly :

  • Generate a new key pair

  • Assign the new public key to the user while keeping the old key:

sql

ALTER USER bridged_user SET RSA_PUBLIC_KEY_2 = 'new_public_key';
  • Update Bridged with the new private key

  • Verify the connection works

  • Remove the old public key:

sql

ALTER USER bridged_user UNSET RSA_PUBLIC_KEY;

Troubleshooting

Issue

Likely cause

Solution

Connection fails

Invalid account identifier

Use format orgname-accountname (find in Snowflake URL)

Key pair authentication fails

Private key format incorrect

Ensure private key is in PKCS#8 format

"Authentication type PASSWORD is deprecated"

Using username/password auth

Switch to key pair authentication

Query timeout

Complex query or large dataset

Optimize query with filters or reduce batch size

No data returned

Incorrect table name or schema

Verify database and schema names in connection

Write fails

Missing INSERT permission

Grant INSERT on target tables to bridged_role

Warehouse not found

Warehouse name incorrect or suspended

Verify warehouse name and auto-resume setting

Rate limiting (queue wait)

Warehouse overloaded

Increase warehouse size or use multi-cluster warehouse

Large file load fails

File exceeds recommended size

Split files into 100-250 MB chunks

OAuth authentication fails

Invalid client ID or secret

Verify OAuth configuration in Snowflake

Common Error Messages

Error

Solution

Incorrect username or password

Verify username and key pair configuration

Warehouse cannot be resumed

Check that warehouse is not dropped or that user has USAGE permission

Object does not exist

Verify database, schema, and table names are correct

Insufficient privileges

Grant required permissions to bridged_role

JWT token is invalid

Regenerate key pair and reassign public key

Support

For integration support, contact your Bridged account manager or email support@bridged.media.

For Snowflake-specific questions, refer to Snowflake documentation or contact Snowflake Support