Zendesk Support to MySQL: How to Move Your Data

Moving Zendesk Support into MySQL lets you ask questions that span support and everything else. Zendesk reports well on tickets, but it cannot tell you which customers cost the most to serve, whether ticket volume predicts churn, or how support load tracks a release, because the data it would need to join against lives somewhere else entirely.

This guide covers the managed path with Airbyte. Two things shape the build: the account you authenticate with silently determines how much of Zendesk you can see, and MySQL's identifier limit collides with the long names that nested Zendesk fields produce.

Zendesk Support to MySQL at a glance:

Why move data from Zendesk Support to MySQL?

Two situations account for most of these pipelines.

The first is joining support to commercial reality. Ticket volume on its own is a workload metric; ticket volume per account, set against contract value and renewal dates, is a business one. Zendesk cannot make that join because it has no idea what a customer pays you, and the answer only appears once tickets sit beside the systems that do.

The second is feeding an application. An internal tool or a customer-facing portal wants current ticket state, and MySQL serves single-record lookups far more cheaply than a warehouse does. That is also where the limit of this pairing sits: guidance for this destination is around ten gigabytes, and a large Zendesk instance with years of tickets, comments and audit history will pass that. If that describes you, the analytical work belongs in a warehouse and MySQL should hold only the slice your application needs.

What do you need before you start?

Four things, and the first one quietly decides what your dataset contains:

An admin account, or a written list of what you are giving up. Several streams require administrator rights, and an account without them does not fail, it simply returns less. Use an admin service account if you can; if policy forbids it, find out which streams you are losing and record the decision somewhere your future self will look.

Credentials and your subdomain. An API token with the associated email address, or OAuth, plus the subdomain that identifies your instance. The Zendesk Support source documentation covers generating a token.

A MySQL database, a user that can create tables, and a volume estimate. Check your ticket count and roughly how many comments and audits sit behind them before committing, since those child records are what actually fill the disk rather than the tickets themselves.

A plan for views. The destination adds its own metadata columns to every table, and anything reading these tables directly will see them. Deciding now that applications and analysts read views rather than raw tables saves renaming things later.

If your database restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.

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

Step 1: Settle which account authenticates, and verify what it sees

Create the credentials from an account whose role you have actually checked rather than from whoever happened to be logged in. Then verify: run a discovery, compare the stream list against what Zendesk documents, and confirm the ones you expected are present. This takes a few minutes and is the only point at which a permissions gap is cheap to notice, because nothing later in the process will mention it.

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, credentials and a start date. If you are on connector version 5.2.0 or later, note that deleted tickets arrive in their own stream rather than inside tickets, and select it if you want them.

Step 3: Configure the MySQL destination

Click Destinations, then New Destination, and select MySQL, following adding a destination. Supply the host, port, database and credentials. Give this its own database or schema rather than dropping Zendesk tables beside your application's own, because the metadata columns and the naming are not what an application developer expects to find.

Step 4: Create the connection and expect the export floor

Click Connections, then New connection, select your streams and a sync mode. Use incremental wherever it is offered, since ticket history only grows. Do not expect a premium Zendesk plan to make the first sync quick, because the incremental export endpoints sit at a hard floor of ten requests per minute no matter what you pay.

Plan for the backfill to take a while and leave it alone. Once it has caught up, daily or hourly syncs are comfortably within both rate limit tiers.

Why does your dataset look complete when it isn't?

Because the two ways data goes missing here both happen quietly. The first is permissions: several streams require an administrator, and an account without that role does not trigger an error. Those streams are simply absent, and a dataset that arrives with no failures and no warnings looks exactly like a complete one.

The second is the change introduced in version 5.2.0, which moved deleted tickets into a stream of their own. Upgrade across that boundary without selecting the new stream and your ticket count falls, which looks alarming and is entirely correct. Anyone comparing a figure from before the upgrade against one from after is comparing two different definitions of ticket.

Both are cheap to guard against and expensive to discover late. Check the discovered stream list against the documented one when you first configure the source, pick a known account and reconcile its ticket count against Zendesk directly, and write down which connector version produced which numbers. A support dataset that silently under-reports is worse than no dataset, because people act on it.

What happens when Zendesk field names meet MySQL?

They get long, and MySQL stops at 64 characters for an identifier. Zendesk records nest, and a nested field arrives flattened into a name built from the path that produced it, so a custom field inside a structure inside a ticket generates something considerably longer than anyone would have chosen by hand. Most fields are fine; a handful in a heavily customised instance are not.

This is worth checking rather than assuming, because the fields most likely to breach the limit are the custom ones your organisation added, which are also the ones your reporting depends on. Look at the generated column names after the first sync and note any that are near the ceiling, since a truncated or rejected name is a problem you would rather find in a test run than in a dashboard.

Views are the answer to this and to the metadata columns the destination adds. Build a view per table that selects the columns people actually need, renames the unwieldy ones to something readable, and leaves the pipeline's own bookkeeping out. Applications and analysts read the views, the pipeline owns the tables, and neither side has to care what the other is doing.

Frequently asked questions

Why are some streams missing from my sync?

Almost always permissions. Streams requiring administrator rights are skipped silently when the authenticating account lacks them, so check the account's role rather than looking for an error message.

My ticket count dropped after upgrading. What happened?

Version 5.2.0 moved deleted tickets into a separate stream. The tickets stream now holds fewer records by design, and selecting the new stream restores the total.

We are on a high Zendesk plan, so why is the first sync slow?

The incremental export endpoints have a floor of ten requests per minute regardless of plan. Plan-based limits apply elsewhere, but that floor governs the backfill and no amount of spend moves it.

Why do my tables have columns I did not expect?

The destination adds metadata columns for its own bookkeeping. Leave them alone and expose views that select only the columns your application or analysts need.

Can I do this without writing code?

The pipeline, yes, since the setup is entirely UI-driven. The views are a modest amount of SQL, and they are what makes these tables pleasant to work with rather than merely present.

Get your Zendesk Support data into MySQL

Check the authenticating account's role before anything else, because a non-admin dataset arrives looking perfectly healthy. Reconcile a known ticket count against Zendesk once, and record the connector version alongside it so a future drop can be explained rather than investigated. Expect a slow backfill whatever your plan, inspect the generated column names for anything near 64 characters, and put views over the tables so nobody downstream has to think about any of this.

Airbyte's connector catalog includes 600+ pre-built connectors, so support history can sit beside the commercial data that gives it meaning. For the same source into a warehouse, see Zendesk Support to BigQuery, and for another permissioned business system into the same destination, Quickbooks to MySQL.

Start syncing now →