Pendo to Snowflake: How to Move Your Data

Moving Pendo into Snowflake puts your product's audience beside the commercial data that explains it. Knowing which visitors belong to which accounts matters far more when set against contract value and renewal risk, and Pendo cannot make that join for you.

This guide covers the managed path with Airbyte. Two things shape the build: every sync reads everything because the endpoints offer nothing to be incremental against, and visitor records describe identifiable people using metadata your own teams defined.

Pendo to Snowflake at a glance:

Why move data from Pendo to Snowflake?

Two situations account for most of these pipelines.

The first is understanding who uses your product commercially. Visitors and the accounts grouping them become genuinely informative once joined to contract value, renewal dates and support history, and that is a warehouse job because no product analytics tool holds those.

The second is governance, since this data describes identifiable end users and Snowflake's access controls suit that better than most destinations. The limit worth stating early is scope: the aggregation endpoint is not supported, so feature usage counts are not part of this and need a separate route.

What do you need before you start?

Four things, and the first needs somebody with admin rights:

An integration key, created by a Pendo admin. Found under Integrations, then Integration Keys. There is a box marked to allow write access; leave it unticked, since this pipeline reads. The Pendo source documentation covers the sequence.

Snowflake objects and a role. A warehouse, database, schema and a role that can create tables. Give this its own schema, since the access controls it needs differ from the rest of your warehouse.

A decision about who reads visitor detail. Visitors are your product's end users, identified and described with whatever metadata your teams chose to send. Most analysis needs none of that detail.

Patience for full refreshes. Every sync reads everything, which is fine for a configuration estate and worth knowing before you schedule this hourly out of habit.

If your Snowflake account restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the network policy before you begin.

How do you build a Pendo to Snowflake pipeline in Airbyte?

Step 1: Get a read-only key from an admin

Only Pendo admins can create and view integration keys, so this is a request rather than something you do yourself, and it is worth making specific. Ask for a key with write access left off and a description naming this pipeline, because a key labelled usefully is one somebody can revoke confidently later rather than leaving in place because nobody knows what it does.

Step 2: Configure the Pendo source

Click Sources in the left navigation, then New Source, and select Pendo, following adding a source. Supply the integration key. Select the streams you need rather than everything, since each one is re-read in full on every sync and the visitors stream grows with your user base.

Step 3: Configure the Snowflake destination

Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role. Visitor and account records carry nested metadata objects, and Snowflake holds those natively, so nothing needs flattening on the way in.

Step 4: Create the connection, then apply the policies

Click Connections, then New connection, select your streams and a sync mode. Daily is ample. Then apply masking before telling anybody the schema exists, because the window between data landing and controls being applied is the window in which somebody browses a table they should not have read.

Then model the metadata, because what arrives inside it depends entirely on what your own teams decided to send.

Why does every sync read everything?

Because there is nothing to be incremental against. The list endpoints this connector uses expose no server-side timestamp filter, so there is no cursor for the connector to carry between runs and no way to ask for only what changed. Full refresh is the honest consequence rather than an omission.

For most of these streams that hardly matters, since features, pages and guides number in the hundreds and re-reading them costs nothing anybody notices. Visitors are the exception, because that stream grows with your user base and a successful product makes this pipeline progressively heavier without anything changing in the configuration.

So select streams deliberately and schedule modestly. Daily is almost always sufficient for data describing how your product is configured and who uses it, and hourly buys nothing when the underlying records change at the pace of product decisions. If the visitors stream becomes genuinely large, that is the moment to ask whether you need every visitor or only those belonging to accounts you care about commercially.

What is actually inside visitor metadata?

Whatever your own engineers decided to send, which is the unusual thing about this dataset. Pendo identifies visitors and accounts, and the metadata attached to them is defined by your product teams rather than by Pendo, so two applications instrumented by different squads can describe their users in entirely different shapes.

That has two consequences. Identifying detail may be richer than anybody expects, since teams instrumenting a product often send email addresses, names or role information without considering that it will one day sit in a warehouse. And the shapes are inconsistent, so a field present for one cohort may be absent or differently typed for another.

Handle both deliberately. Look at what the metadata actually contains before granting anybody access, then apply masking policies to the identifying fields so analysts can count visitors per account without reading who they are. And use TRY_CAST when pulling values out of those nested objects, because a plain cast will stop a query dead on the one cohort whose instrumentation sent a number as text.

Frequently asked questions

Why is there no incremental option?

The list endpoints offer no server-side timestamp filter, so there is no cursor to read from. Full refresh is the consequence rather than an oversight.

Can I get feature usage from this?

No. The aggregation endpoint is not supported and that is where event data lives, so usage analysis needs a different route entirely.

Should analysts see visitor identities?

Rarely. Counting visitors per account and measuring adoption need no identifying values, so mask them and grant the real values only where there is a clear reason.

Why do metadata fields differ between users?

Because your own teams defined what to send, and instrumentation varies across products and squads. Use TRY_CAST when extracting values rather than assuming consistency.

Can I do this without writing code?

The pipeline, yes. Masking policies and the views extracting metadata safely are SQL, and with end-user data they are not optional.

Get your Pendo data into Snowflake

Ask an admin for a read-only integration key with a description naming this pipeline. Select streams deliberately and schedule daily, since every sync reads everything and the visitors stream grows with your product's success. Then look at what your own instrumentation actually put in visitor metadata before granting access, apply masking to the identifying parts, and use TRY_CAST when reading values your teams defined inconsistently.

Airbyte's connector catalog includes 600+ pre-built connectors, so product audiences can be understood alongside the commercial reality. For attribution data with similar governance needs, see Appsflyer to Snowflake, and for the customer records to join against, Salesforce to Snowflake.

Start syncing now →