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 -nocryptImportant: 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 passwordStep 2.4: Configure Bridged to Connect Using Key Pair
Log in to your Bridged dashboard.
Navigate to the Integrations section. If you do not see this section, contact
support@bridged.media.Click Snowflake → Connect Account.
Choose Key Pair as your authentication method.
Enter the following credentials:
Field | Description | Where to find |
|---|---|---|
Account | Snowflake account identifier | Format: |
Username | Bridged user name |
|
Private Key | Content of private key file | The entire content of |
Warehouse | Virtual warehouse name |
|
Database | Database name |
|
Schema | Schema name |
|
Role (optional) | Snowflake 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 .
In Bridged, navigate to Integrations → Snowflake → Connect Account.
Choose Username/Password as your authentication method.
Enter the following credentials:
Field | Description |
|---|---|
Account | Snowflake account identifier (e.g., |
Username |
|
Password | The user's password |
Warehouse |
|
Database |
|
Schema |
|
Role (optional) |
|
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
In Bridged, navigate to Integrations → Snowflake → Connect Account.
Choose OAuth as your authentication method.
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 |
|
Database |
|
Schema |
|
Click Connect with OAuth.
You will be redirected to your identity provider to authenticate.
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., | 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
In Bridged, go to Integrations → Snowflake → Test Connection.
Verify that the connection is successful and the warehouse is accessible.
Run a test read query to verify SELECT access.
Create a test record in Snowflake and verify Bridged can read it.
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 |
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 |
|---|---|
| Verify username and key pair configuration |
| Check that warehouse is not dropped or that user has USAGE permission |
| Verify database, schema, and table names are correct |
| Grant required permissions to bridged_role |
| 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