Zendesk Support to Snowflake: How to Move Your Data
Move Zendesk Support into Snowflake with Airbyte. Why some incremental streams never get cheaper, and where support measures actually come from.
Moving Zendesk Support into Snowflake lets you measure support properly and join it to everything else. Zendesk reports on tickets; whether customers who raised them renewed, and what serving them cost, needs commercial data beside the support record.
This guide covers the managed path with Airbyte. Two things shape the build: the word incremental covers two quite different behaviours here, and the measures people care about are spread across several streams rather than sitting in one.
Zendesk Support to Snowflake at a glance:
Why move data from Zendesk Support to Snowflake?
Two situations account for most of these pipelines.
The first is measuring support against outcomes rather than activity. Ticket counts are easy; whether customers who contacted you three times renewed, and what those contacts cost to serve, needs support data beside contracts and revenue.
The second is governed access, since ticket comments contain whatever customers wrote. If your priority is interactive aggregation over a very large ticket history rather than joins and controls, a column store suits that shape better.
What do you need before you start?
Four things, and the third changes how you read your sync times:
Your subdomain and a chosen authentication method. The subdomain is the part before zendesk.com in your account URL, and OAuth with a refresh token is the recommended option on Airbyte Cloud. The Zendesk Support source documentation covers all three.
Snowflake objects and a narrow grant. A warehouse, database, schema and a role that can create tables. Give this its own schema, because ticket comments are not something to leave in a general reporting area.
An understanding of which streams filter where. Some streams get only changed records from the API and others fetch everything and filter locally, which explains sync durations that otherwise look wrong.
A list of the support measures you want. First response time and resolution time are derived from several streams, so knowing which measures matter tells you which streams are load bearing.
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 Zendesk Support to Snowflake pipeline in Airbyte?
Step 1: Work backwards from the measures
Write down what support leadership actually wants to know, then map each measure to the streams it needs, because almost none of them come from tickets alone. First response time, resolution time and reopen rates are derived from events and comments attached to a ticket rather than from fields on it. That mapping is both your stream selection and the outline of your silver layer.
Step 2: Configure the Zendesk Support source
Click Sources in the left navigation, then New Source, and select Zendesk Support, following adding a source. Supply the subdomain, your chosen authentication and a start date. The concurrent workers setting controls how many streams sync in parallel, and raising it helps only if your plan tier allows it.
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. Ticket records carry nested custom fields and tags, and Snowflake holds those natively, so nothing needs flattening on the way in.
Step 4: Create the connection and apply controls
Click Connections, then New connection, select your streams and a sync mode. Deduped history suits ticket data, since tickets change throughout their life. Then mask the comment bodies before telling anybody the schema exists, because most analysis counts rather than reads.
Then build the silver layer, because the landing tables describe Zendesk's objects rather than your support process.
Which streams actually fetch less?
Only some of them, because this connector supports two different kinds of incremental sync. The first is the one people assume: the API is asked for records created or updated since the last run, and returns only those. The second fetches everything available and has the connector filter out the new records itself.
Both produce correct tables and only the first saves you anything at the API. A client-side incremental stream costs the same to sync on day one hundred as on day one, which explains sync durations that look disproportionate to how little changed, and it is worth knowing before anybody investigates a pipeline that is behaving as designed.
That shapes how you schedule. Streams filtering locally do not get cheaper as your cursor advances, so they are the ones to sync less often or to place on their own connection. The concurrency setting helps by running more streams in parallel where your plan tier permits, which is a different lever from asking for less data and worth using alongside rather than instead.
Where do support measures actually come from?
From several streams assembled together, which is the real work of this pipeline. A ticket record tells you a ticket exists, who it belongs to and its current status. It does not tell you when an agent first replied, how long it sat waiting or how many times it was reopened.
Those live in the comments and metric event streams, as timestamps you have to pair with the ticket they belong to. First response time is the gap between a ticket opening and the first agent comment; resolution time spans status changes. Neither is a field you select, and both are exactly what support leadership asks for.
So build a silver table with one row per ticket carrying those derived durations, and treat the definitions as the deliverable. Teams disagree about whether an automated reply counts as a first response, and about whether time outside business hours counts at all, and having those answers written into one modelled table is what stops two dashboards reporting different numbers for the same week.
Frequently asked questions
Why is an incremental stream not getting faster?
It is probably client-side incremental, meaning the API returns everything and the connector filters. Those streams cost the same regardless of how little changed.
Can I get first response time directly?
No. It is derived by pairing a ticket with its comments or metric events, which is why the silver layer matters more than the landing tables here.
Which authentication should I use?
OAuth with a refresh token is recommended on Airbyte Cloud. An API token alongside the account email is the usual alternative.
Should analysts read ticket comments?
Rarely. Comments contain whatever customers wrote, and measures like response time and volume need none of that text, so mask it and grant access deliberately.
Can I do this without writing code?
The pipeline, yes. Deriving support measures from timestamps across streams is modelling work, and it is where the value of this project sits.
Get your Zendesk Support data into Snowflake
Map your support measures to streams before selecting anything, since almost none of them come from tickets alone. Expect two kinds of incremental behaviour, and schedule the streams that filter locally less often because they never get cheaper. Then mask comment bodies, and put the effort into a silver table carrying agreed definitions of first response and resolution time.
Airbyte's connector catalog includes 600+ pre-built connectors, so support activity can be measured against the customers it served. For the same source into another warehouse, see Zendesk Support to BigQuery, and for customer conversations into the same destination, Gong to Snowflake.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.