Pipedrive to BigQuery: How to Move Your Data

Moving Pipedrive into BigQuery gets sales data out of a tool built for salespeople and into a warehouse where it can be joined against revenue, product usage and support cost. Pipedrive tells you what was sold and by whom. It does not know whether those customers stayed, and the questions worth asking need both.

This guide covers the managed path with Airbyte. The connector is straightforward to set up and has one configuration behaviour that is easy to miss, because a field most people treat as a scope setting also determines whether your streams sync incrementally at all.

Pipedrive to BigQuery at a glance:

Why move data from Pipedrive to BigQuery?

Two situations account for most of these pipelines.

The first is joining the commercial picture together. Pipedrive knows what closed. Your billing system knows whether it was paid for, your product knows whether anyone used it, and your support tool knows what it cost to serve. None of those questions can be answered inside a CRM, and all of them can be answered in a warehouse.

The second is analysis Pipedrive is not built for. Multi-year pipeline trends, cohort analysis of deals by source, forecasting that involves data from outside the CRM. Moving the data lets analysts use SQL and leaves Pipedrive to serve the sales team, which is what it is good at.

What do you need before you start?

A short list, and two items that decide how the pipeline behaves rather than whether it connects:

A Pipedrive API token. Found in the Pipedrive settings under personal preferences, on the API tab. Note the word personal: the token belongs to a user account and inherits what that user can see, so a token generated from a sales representative's login produces a dataset shaped by their visibility.

A dedicated account to own it. Following from the above, create the token against an account with deliberately scoped access rather than an individual's. A pipeline that breaks when somebody leaves, or whose contents change when their permissions do, is a pipeline you will be debugging later.

A start date, entered deliberately. Supplied as a UTC datetime. Data before this point is not replicated, and specifying it is also what makes streams behave incrementally, which is covered below and is the reason to treat this field as a design decision.

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 before you begin.

How do you build a Pipedrive to BigQuery pipeline in Airbyte?

Step 1: Create the token on a dedicated account

Set up an account for the integration with visibility across the deals and contacts your analysts need, then generate its API token from the settings menu under personal preferences and the API tab. Write down what that account can see, because it is now part of your data model rather than an administrative detail.

Step 2: Configure the Pipedrive source

Click Sources in the left navigation, then New Source, and select Pipedrive, following adding a source. Supply the API token and the start date in UTC. Airbyte validates the configuration by attempting to read the deals stream, so a check failure usually means the token cannot see deals rather than that the token is invalid.

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, since even a large Pipedrive account is small by warehouse standards.

Step 4: Select core and reference streams together

Click Connections, then New connection, and select streams with a sync mode each. Take the core entities you need, deals, persons, organizations, activities, leads and notes, and take the reference streams alongside them. Pipelines, stages and users are small and rarely change, and without them your deal records reference stages and owners by identifier with nothing to resolve them against.

Daily is a sensible cadence for CRM data, which changes at the speed of sales conversations rather than continuously. Build the joining views early, because a deals table full of stage identifiers is technically complete and practically unusable.

Why is the start date more than a scope setting?

Because it changes how streams sync, not just how much they return. The connector's own description of the field says that any data before this date will not be replicated, and that when the value is specified, the stream will behave as incremental.

That is unusual. On most connectors the start date bounds a backfill and the sync mode is a separate choice made on the connection. Here the two are linked, which means a vague or missing start date is not a harmless default, it changes the behaviour of every run rather than just the first one.

So set it explicitly, in UTC, to the earliest date anyone will actually query. On a CRM that has been running for years, that is rarely the beginning of time, and choosing it thoughtfully gives you incremental behaviour and a sensible first sync in the same decision.

How should you model Pipedrive data in BigQuery?

Start with the joins that turn identifiers into meaning. A deal references its stage, its pipeline, its owner and the organisation it belongs to, all by ID. A view resolving those into names is the first thing to build, and it is what makes the difference between a dataset analysts use and one they ask you about.

Custom fields deserve attention next. Pipedrive lets teams add their own fields, and they arrive under generated identifiers rather than the labels people use in the interface. Map them once in a view rather than leaving every analyst to work out which field holds the contract length.

Finally, define your pipeline metrics in one place. Win rate, average cycle time and stage conversion are derived measures rather than fields, and two teams computing them slightly differently causes more disagreement than any pipeline fault. Put them in a view and point everyone at it.

Frequently asked questions

Do I have to set a start date?

You should. Data before it is not replicated, and specifying it is what makes streams behave incrementally, so it affects every sync rather than only the first.

Why does my connection check fail?

The connector validates by reading the deals stream, so a failure often means the token's account cannot see deals rather than that the token itself is wrong.

Why are some records missing?

The API token belongs to a user account and inherits its visibility, so records that account cannot see do not reach BigQuery. Check the account's permissions before the connector.

Why are my custom fields named after identifiers?

Pipedrive exposes custom fields under generated identifiers rather than their display labels. Map them once in a downstream view so analysts see meaningful names.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven. You will want BigQuery views resolving identifiers to names and defining your pipeline metrics, which is short SQL.

Get your Pipedrive data into BigQuery

Create the token on a dedicated account and document what it can see, set the start date explicitly because it governs incremental behaviour, take the reference streams alongside the core ones, and build the joining views before anyone queries the raw tables.

Airbyte's connector catalog includes 600+ pre-built connectors, so CRM data can sit beside billing and product sources in one warehouse. For a larger CRM with a very different rate limit model, see Salesforce to Snowflake, and for marketing engagement on the same customers, Braze to BigQuery.

Start syncing now →