Zendesk Support to BigQuery: How to Move Your Data

Moving Zendesk Support into BigQuery is how support stops being measured in isolation. Zendesk knows how long tickets take and who resolved them. It does not know what those customers pay, whether they churned afterwards, or which product area generated the volume, and every useful question about support involves at least one of those.

This guide covers the managed path with Airbyte. Two things are worth knowing before you build: an account without the right role produces a quietly incomplete dataset, and the streams you most want are capped by a rate limit that no amount of paying Zendesk will raise.

Zendesk Support to BigQuery at a glance:

Why move data from Zendesk Support to BigQuery?

Two situations account for most of these pipelines.

The first is cost to serve. Support volume next to revenue tells you which customers or plans are expensive to keep, which is a question that decides pricing and account management and cannot be answered inside a helpdesk.

The second is product feedback at scale. Ticket volume by area, joined to release dates and usage, turns support into an early warning system rather than a queue. Both need history and joins, and Zendesk's own reporting offers neither in the form you want.

What do you need before you start?

The first item is the one that quietly determines whether your dataset is complete:

An account with the administrator role. An administrator role is recommended for full access to all streams. Non-admin accounts can still sync, and streams requiring admin permissions are automatically skipped rather than failing, so a lesser account gives you a smaller dataset and no warning. The Zendesk Support source documentation covers the requirements.

Your subdomain and credentials. The subdomain is the part before zendesk.com in your URL. Authenticate with an API token alongside the account email, or with OAuth, which is the more comfortable option on Airbyte Cloud.

Your Zendesk plan tier. Rate limits vary by tier, and knowing yours tells you whether raising the concurrency setting will help. It also will not help on some streams, for the reason below.

A BigQuery service account and dataset. With the BigQuery User and BigQuery Data Editor roles. Set the dataset location to match the datasets holding your revenue and product data, since joining them is the point.

If you already run this connector on a version before 5.2.0, note that the tickets stream no longer includes deleted tickets. Read the migration guide before upgrading, because your ticket counts will change.

How do you build a Zendesk Support to BigQuery pipeline in Airbyte?

Step 1: Get an admin account for the integration

Ask for an administrator account dedicated to this pipeline rather than reusing somebody's login. That covers both the completeness problem and the usual one of a pipeline that breaks when a person leaves. It is a small request and it prevents the most likely failure on this connector, which is a dataset that looks fine and is missing streams.

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. Leave the concurrency setting alone for now, since its usefulness depends on which streams you select.

Step 3: Configure the BigQuery destination

Click Destinations, then New Destination, and select BigQuery, following adding a destination. Supply the project, dataset and service account key. Batched standard inserts is the default and is adequate, since support data is modest by warehouse standards even on a busy helpdesk.

Step 4: Take deleted tickets alongside tickets

Click Connections, then New connection, and select streams with a sync mode. Tickets, ticket comments, users and organizations cover most analysis. Add the deleted tickets stream too, because since version 5.2.0 that is the only place deletions appear and without it a removed ticket simply lingers in your warehouse.

One reassurance about the tickets stream. It reads through Zendesk's export search endpoint, and Zendesk's search index can take a few minutes to reflect new or updated tickets. That delay does not cause data loss during incremental syncs, because the cursor ensures those records are picked up on the next run.

Why will a bigger Zendesk plan not speed this up?

Because two different limits are at work. Zendesk applies general rate limits that vary by plan tier, and the connector's concurrency setting lets you use more of that budget by syncing more streams in parallel, up to a maximum of forty.

Separately, Zendesk's incremental export endpoints are capped at ten requests per minute regardless of plan tier. That applies to ticket comments, ticket metric events, users and organizations, which on most accounts are exactly the streams carrying the most data. Paying for a higher tier does not move that number and neither does raising concurrency.

So set expectations accordingly. A first sync on a helpdesk with years of ticket comments will take as long as that floor allows, and the useful levers are a later start date and deselecting streams nobody queries. Raising the thread count helps the lighter streams and does nothing for the heavy ones.

Where did the deleted tickets go?

Into their own stream. As of version 5.2.0 the tickets stream no longer includes deleted tickets, and a dedicated deleted tickets stream carries them instead. This is a documented behaviour change with a migration guide rather than a bug, and it has a consequence in both directions.

If you are upgrading, your ticket counts will change, because rows that used to appear no longer do. Anyone comparing this month against last month across that upgrade will see a step that has nothing to do with support volume, so warn them before it happens rather than explaining afterwards.

If you are building fresh, simply select both streams. The separation is arguably cleaner than the old behaviour, since deleted tickets are a different thing analytically from open ones, and having them in a separate table makes that distinction explicit rather than something every query has to filter for.

Frequently asked questions

Why are some streams missing from my sync?

Your account probably lacks the administrator role. Streams requiring admin permissions are skipped automatically rather than raising an error, so the dataset looks complete and is not.

Why did my ticket counts drop after an upgrade?

As of version 5.2.0 the tickets stream no longer includes deleted tickets. Add the deleted tickets stream, and see the migration guide for the details.

Will more concurrent threads make my sync faster?

Only where your plan's general rate limit is the constraint. The incremental export endpoints are capped at ten requests per minute regardless of tier, so the heaviest streams do not speed up.

Does Zendesk's search index delay lose data?

No. The index can take a few minutes to reflect new or updated tickets, and the connector's cursor ensures those records are picked up on the next sync.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven. You will want BigQuery views joining tickets to your customer and revenue data, which is where the cost to serve analysis lives.

Get your Zendesk Support data into BigQuery

Use an administrator account, because a lesser one silently skips streams. Select deleted tickets alongside tickets, set expectations about the first sync given the export endpoint floor, and warn your analysts before upgrading across the 5.2.0 change so a step in the numbers does not get mistaken for a change in support volume.

Airbyte's connector catalog includes 600+ pre-built connectors, so support data can sit beside the revenue and product sources that explain it. For payment data in the same warehouse, see Stripe to BigQuery, and for the CRM side of the same customers, HubSpot to BigQuery.

Start syncing now →