Zoho CRM to BigQuery: How to Move Your Data

Moving Zoho CRM into BigQuery gets sales data out of a tool built for salespeople and into a warehouse where it can be joined against billing, product usage and support cost. Zoho knows what closed and who closed it. It does not know whether the customer stayed, and margin questions need both.

This guide covers the managed path with Airbyte. The unusual thing about this connector is that it does not have a fixed stream list: it builds one from your own Zoho configuration, which means the tables you end up with are unique to your organisation.

Zoho CRM to BigQuery at a glance:

Why move data from Zoho CRM to BigQuery?

Two situations account for most of these pipelines.

The first is joining the commercial picture. Zoho holds deals and contacts, your billing system holds what was paid, and your product holds whether anyone used it. Questions spanning all three need one place to query, and no CRM can answer them alone.

The second is reporting Zoho is not built for: multi-year pipeline trends, cohort analysis of deals by source, forecasting that pulls in data from outside the CRM. If you only need standard pipeline reports, Zoho already produces those and this pipeline earns you nothing.

What do you need before you start?

The credentials are ordinary and three of these fields decide what the pipeline can do:

OAuth credentials. A client identifier, client secret and refresh token from a Zoho API client, with read scopes for modules and their metadata. The Zoho CRM source documentation covers the setup.

Your data centre region and environment. Zoho operates several regions, and the environment is production, developer or sandbox. Both are configuration choices rather than things the connector discovers, and the wrong region produces a connection that cannot find your data.

Your Zoho edition and its credit allowance. Zoho CRM API calls are associated with credits, and each edition has a limit within a 24-hour rolling window. The edition also determines which modules are available at all, so it constrains what you can have and how often you can fetch it.

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 billing and product data, since it cannot be changed after creation and BigQuery only joins datasets in the same location.

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

How do you build a Zoho CRM to BigQuery pipeline in Airbyte?

Step 1: Establish your edition and credit budget

Find out which Zoho edition you are on, what credit allowance that gives you in a rolling day, and what else in your organisation already consumes it. Those numbers set your sync frequency and your stream selection, and they are much easier to establish now than after a connection starts exhausting the allowance for everybody.

Step 2: Configure the Zoho CRM source

Click Sources in the left navigation, then New Source, and select Zoho CRM, following adding a source. Supply the OAuth credentials, then set the region, environment and edition, and a start sync date. Schema discovery runs against Zoho's metadata and generally takes ten to thirty seconds, so a much longer wait usually means one of those three fields is wrong.

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 loading method and is ample here, because even a large Zoho instance is small by warehouse standards.

Step 4: Select modules and schedule against credits

Click Connections, then New connection, and select the modules your analysts need with a sync mode each. Both full refresh and incremental are supported. Use incremental where you can and set the frequency against your credit allowance rather than how fresh anyone would like it, since CRM records change at the speed of sales conversations.

If you prototyped against a developer environment, re-run discovery when you point at production. The two are not equivalent, and the developer environment contains substantially fewer modules.

Why is your stream list unique to your organisation?

Because the connector builds its streams dynamically from Zoho's metadata APIs. The list of available streams is the list of modules for which module metadata and field metadata can be retrieved, so the catalogue reflects your configuration rather than a fixed set someone else would recognise.

That is mostly an advantage. Custom modules your team built appear automatically, because they carry metadata like any other, which beats a connector with a hardcoded list on a heavily customised instance. And when a module you expected is missing, the diagnosis is clear: the Zoho API is not making it available to you, usually because of your edition or your permission scopes, so the fix is in Zoho.

The cost is documentation. Nobody can look up what your Zoho tables contain, because no two Zoho warehouses are alike, so write down what you selected and what each custom module is for. On a dataset analysts will inherit from you, that note is worth more than any amount of tidy modelling.

What do you do about the string-typed fields?

Any data type outside the connector's mapping is treated as a string. On a CRM full of custom fields that is a meaningful set: currency amounts, percentages, custom pick lists and anything a Zoho administrator invented all have a reasonable chance of arriving as text.

So the landed table is a raw layer rather than something to query directly. Build a view casting each column to what it actually is, and make the choice per column rather than applying one rule. BigQuery gives you both options: a safe cast turns a bad value into null and keeps the pipeline quiet, and a plain cast fails loudly.

Choose loudly for anything financial. A deal value with stray text in it should break your build rather than silently become null, because a null quietly drops out of a sum and nobody notices the total is wrong. Free-text notes and optional attributes are the opposite case, where a safe cast is exactly right.

Frequently asked questions

Why is a module missing from my stream list?

Because the Zoho CRM API does not make it available to you, usually due to your edition or your permission scopes. The fix is in Zoho rather than in Airbyte.

Do my custom modules appear?

Yes, provided Zoho exposes metadata for them. Streams and schemas are built dynamically from the modules and fields metadata APIs.

Why are some fields arriving as text?

Any data type outside the connector's mapping is treated as a string. Cast those columns in a BigQuery view, choosing a safe or strict cast per column depending on how bad values should behave.

How often should I sync?

Against your edition's credit allowance in a 24-hour rolling window, shared with everything else connected to Zoho. Daily suits most CRM reporting.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven. You will want BigQuery views casting the string-typed columns, which is short SQL and where this dataset becomes usable.

Get your Zoho CRM data into BigQuery

Establish your edition and credit allowance before choosing a schedule, set the region and environment deliberately, re-run discovery against production if you prototyped elsewhere, and cast the string-typed columns in a view. Then document your catalogue, because nobody else can look up what your Zoho tables contain.

Airbyte's connector catalog includes 600+ pre-built connectors, so CRM data can sit beside product and billing sources in one warehouse. For the same source feeding a lakehouse, see Zoho CRM to Databricks, and for a lighter CRM in the same position, Pipedrive to BigQuery.

Start syncing now →