CUSTOMER DATA INFRASTRUCTURE
The missing link between Snowflake and Iterable
Iterable expects userId or email, event names, and `dataFields` in a specific shape. Snowflake has user IDs that don't match. Meiro Pipes resolves the identity gap, translates your schema into Iterable's API format, manages list membership, and keeps profiles enriched in both directions — without custom ETL you'll spend quarters maintaining.
Free trial · No credit card · Live in minutes
Everyone says Snowflake and Iterable integrate. Nobody warns you about what breaks.
Identity is the first obstacle. Iterable's model centers on two primary keys: userId and email. In many deployments, email is the canonical identifier — not optional, but the primary lookup key. Snowflake stores customers by internal user IDs, Salesforce account IDs, or both. When these don't resolve to an Iterable email, records create duplicate profiles, land on the wrong user, or are silently dropped. No standard connector handles this resolution.
Iterable has two distinct data models. User profiles update via a flat dataFields dictionary — send what you want set, omit the rest. Events use the Track API: eventName, createdAt, userId or email, and a typed dataFields object. Catalog event types like order.purchased and cart.abandon have strict schemas that Iterable uses for revenue attribution and suppression — wrong shape, silent rejection. Deciding which fields to include, which to omit, and how to handle nulls requires logic that doesn't exist in a standard reverse ETL connector.
List management adds another gap. Iterable campaigns are list-based: syncing audiences means computing membership deltas and calling subscribe/unsubscribe APIs separately from profile updates — not a feature most connectors provide. Getting behavioral data from Iterable back into Snowflake requires an S3 export pipeline with its own schema drift and latency. The complete collect-enrich-activate loop needs at least three separate tools.
Five ways the Snowflake → Iterable pipeline breaks
Identity mismatch
Problem
Snowflake has user_id. Iterable uses email as the primary key in most configurations. When they don't match, records create duplicate profiles, land on the wrong user, or are silently dropped. No connector reconciles this.
Meiro solves it
Pipes resolves identity across every identifier type — email, user_id, phone, external ID, CRM account ID — using deterministic matching with configurable merge limits. One unified profile, regardless of which system the identifier originated from.
Event schema rigidity
Problem
Iterable requires events with eventName, createdAt, userId or email, and a typed dataFields object. Catalog events (order.purchased, cart.abandon) have strict property schemas used for revenue attribution. Your Snowflake events don't match this shape.
Meiro solves it
Pipes transform functions convert Snowflake rows into Iterable-compatible event payloads automatically. JavaScript transforms handle field mapping, type coercion, catalog event formatting, and dataFields construction — without maintaining transformation SQL in your warehouse.
User update and `dataFields` model
Problem
Iterable's user update API uses a flat dataFields dictionary. There's no partial-update schema like Braze attributes — you send what you want set. Deciding which fields to include, handling null values, and managing profile state requires custom logic outside Snowflake.
Meiro solves it
Pipes models your Snowflake data as profile attributes before delivery. You define what to include in each sync. Pipes constructs the correct dataFields payload, handles field inclusion/exclusion, and serializes types in the format Iterable expects — no raw API construction.
List membership management
Problem
Iterable campaigns are list-based. Syncing Snowflake audiences to Iterable means computing current list membership, calculating deltas (who joined, who left), and calling subscribe/unsubscribe APIs separately from profile updates. Standard reverse ETL tools don't handle this.
Meiro solves it
Pipes treats list membership as a first-class sync operation. Define audience logic in your data model. Pipes computes membership changes and sends the correct list subscribe or unsubscribe calls automatically — no custom delta computation required.
No enrichment loop
Problem
Getting engagement data from Iterable back into Snowflake requires an S3 export pipeline with its own latency, schema drift, and failure modes. Enriching models with that data and pushing results back to Iterable is multi-step infrastructure work, not configuration.
Meiro solves it
Pipes collects from both directions. Iterable engagement events flow into Snowflake. Snowflake enriches profiles. Enriched profiles and list memberships sync back to Iterable on a schedule or in real time. One platform, bidirectional, identity-resolved.
One pipeline. Identity-resolved. Schema-aware.
Collect from Iterable
Iterable engagement data — email opens, clicks, conversions, custom events — flows into Pipes via webhook or export. Events land without replacing your existing Iterable setup.
Load & Model in Snowflake
Events land in Snowflake automatically. Pipes connects directly — browse tables, map columns, join with CRM data, product usage records, or any warehouse source. Snowflake remains your source of truth.
Resolve Identity
Pipes stitches profiles across Iterable userIds, email addresses, Snowflake user_ids, and any other identifier. Deterministic matching with configurable limits. No duplicate profiles. No dropped records.
Activate Back to Iterable
Enriched profiles push back to Iterable with correctly formatted dataFields, properly shaped catalog events, and list membership changes — all via the right Iterable API endpoints. Scheduled or real time. No custom ETL.
Use case: Onboarding sequence powered by product usage from Snowflake
Your product team tracks feature adoption in Snowflake — every user action, module activation, and API call. You want to trigger a targeted onboarding sequence in Iterable based on which features a customer has and hasn't used in their first 14 days.
The problem: Snowflake has user_id keyed records. Iterable has those users by email. Your feature adoption data is a set of booleans and timestamps per user — not events Iterable can trigger off directly.
Without Meiro: You'd need to write a job that joins Snowflake feature adoption data to your users table, resolves email from user_id, formats a dataFields payload for each user, calls Iterable's user update API in batches, and separately subscribes qualifying users to the correct Iterable list for the onboarding campaign trigger. Any schema change breaks the job.
With Meiro Pipes: Feature adoption data is modeled as profile attributes in Meiro. Pipes resolves user_id to Iterable email using the identity graph. The enriched profile — including feature flags and days-since-signup — pushes to Iterable via the user update API in the correct dataFields format. Users who meet the onboarding criteria are subscribed to the right Iterable list automatically. Your lifecycle team triggers the campaign from list membership.
Time from data model to live Iterable campaign: hours, not sprints.
Pipes speaks Iterable's schema so your Snowflake doesn't have to
Your Snowflake table
SELECT
user_id,
email,
signup_date,
feature_a_activated,
feature_b_activated,
days_since_signup,
account_tier,
updated_at
FROM analytics.user_feature_adoption
WHERE updated_at > CURRENT_DATE - 1Pipes transform
// Pipes send function (Event Destination)
async function send(payload, headers) {
return payload.events.map(row => ({
email: row.email,
userId: row.user_id,
dataFields: {
account_tier: row.account_tier,
feature_a_activated: row.feature_a_activated,
feature_b_activated: row.feature_b_activated,
days_since_signup: row.days_since_signup,
signup_date: new Date(row.signup_date)
.toISOString()
}
}));
}What Iterable receives
{
"email": "[email protected]",
"userId": "usr_8472",
"dataFields": {
"account_tier": "growth",
"feature_a_activated": true,
"feature_b_activated": false,
"days_since_signup": 7,
"signup_date":
"2026-04-10T00:00:00.000Z"
}
}No raw API construction. No batch-management code. Pipes handles serialization, identity resolution, schema compliance, and delivery — and adapts when your Snowflake schema changes.
The cost of bolting it together
The standard stack
- Custom ETL job — join Snowflake tables, resolve email from `user_id`, batch API calls
- Manual `dataFields` construction per entity type
- No identity resolution, silent failures when `user_id` and email diverge
- Separate list subscribe/unsubscribe logic — not handled by any standard connector
- Iterable S3 export → Snowflake load for engagement data — multi-step with schema drift
- Another pipeline to monitor, another failure surface
- Breaks on every Snowflake schema change or new field addition
Meiro Pipes
- Native connectors for Iterable and Snowflake
- Deterministic identity matching across `userId`, email, `user_id`, CRM ID
- Configurable merge limits — no duplicate profiles
- JavaScript sandbox transforms, not raw SQL
- List membership sync as a first-class operation — computes deltas automatically
- Bidirectional: Iterable engagement events land in Snowflake automatically
- Correct `dataFields` format, correct types, every sync
A reverse ETL tool syncs rows. It doesn't resolve identity, manage list membership, or handle the enrichment loop. Meiro Pipes does all of that — and the pipeline that remains is one you can actually maintain.
One platform. Two problems solved.
For the Lifecycle Marketer
You want to build Iterable campaigns that trigger based on product behavior and purchase history — data that lives in Snowflake and isn't available in Iterable today.
- Describe the audience you need — Piper builds it
- Warehouse-enriched profile attributes appear in Iterable without engineering tickets
- Feature adoption, LTV, churn risk — all available as Iterable `dataFields`
- Build campaigns on complete customer context, not just Iterable engagement data
- Audience sync to Iterable lists happens automatically — no manual CSV exports
For the Data Engineer
You're tired of maintaining the Snowflake → Iterable pipeline. The email resolution logic. The `dataFields` construction code. The list delta computation that breaks whenever a new segment is added.
- Connect Snowflake and Iterable once — Pipes handles schema translation
- JavaScript transforms replace raw API payload construction
- Identity resolution across `userId`, email, `user_id`, CRM ID
- Bidirectional sync — Iterable engagement events land in Snowflake automatically
- CI/CD-native config management via mpcli — version-control your pipeline
Under the hood
Iterable Event Destination
Native connector. Pushes user profile updates, custom events, and catalog events (order.purchased, cart.abandon, etc.) to Iterable in the correct API format. Handles dataFields serialization, ISO 8601 date formatting, and list subscribe/unsubscribe calls.
Snowflake Connector
Direct warehouse connection. Browse schemas, tables, columns. Map identifier columns to Meiro identity types. Model warehouse data as profile attributes, events, or audience definitions.
Identity Resolution
Deterministic stitching across email, userId, user_id, phone, device ID, and CRM IDs. Configurable maxIdentifiers and merge priority to prevent false merges. Resolves the Snowflake user_id → Iterable email gap automatically.
Transform Sandbox
Sandboxed JavaScript functions for schema translation. Convert Snowflake rows to Iterable-compatible payloads. Map fields, coerce types, construct dataFields dictionaries, format catalog events. 47 allowlisted packages available.
Reverse ETL / Profile Sync (Customer Studio)
Scheduled or real-time Live Profile Sync. Push enriched profiles, events, and list membership changes to Iterable. On-demand exports for backfills. Full delivery history and retry logic.
List Membership Sync
Model Snowflake-derived audiences as Iterable list memberships. Pipes computes membership deltas between runs and issues the correct subscribe/unsubscribe API calls. No manual delta logic required.
Why connecting Snowflake and Iterable requires more than a connector
Identity is the first obstacle. Iterable's data model is built around email as the canonical identifier in many deployment configurations — userId is optional and often used as a secondary key. Snowflake stores customers by internal user_id, Salesforce account ID, or email depending on the system of record. When these identifiers diverge, syncs silently fail, create duplicate profiles, or associate data with the wrong user. No standard reverse ETL connector reconciles cross-system identity.
Event schema is the second obstacle. Iterable's Track API has specific structural requirements: eventName, createdAt in ISO format, userId or email for attribution, and a typed dataFields object. Iterable's catalog event types — order.purchased, cart.abandon, product.viewed — have strict schemas that the platform uses for revenue attribution, suppression logic, and cross-channel reporting. Snowflake events don't arrive in this shape. Maintaining the transformation is ongoing engineering work.
The user update model adds a third layer. Iterable profiles are updated via a dataFields dictionary — a flat key/value map of all properties you want to set. Deciding which fields to include in each sync, how to handle deletions versus omissions, and how to manage profile state across multiple data sources requires logic that doesn't belong in raw SQL.
List management compounds all of this. Iterable is a list-first platform. Getting Snowflake-derived audiences into Iterable as list memberships means computing current list state, calculating who joined and who left, and issuing subscribe and unsubscribe calls separately from the profile update API. This is not a feature most reverse ETL tools provide.
The enrichment loop closes the gap. Behavioral data from Iterable can reach Snowflake via S3 export — a multi-step pipeline with its own latency and schema drift. Running the complete loop (collect from Iterable, enrich in Snowflake, push back) requires infrastructure that most teams assemble from three or four separate tools.
Stop debugging the pipeline. Start activating the data.
Connect Snowflake and Iterable through Meiro Pipes. Identity-resolved. Schema-aware. Bidirectional. Start free.