Aircall to BigQuery: How to Move Your Data

Moving Aircall into BigQuery connects phone activity to everything that happens around it. Aircall knows who called, when, for how long and who answered. It does not know whether that call preceded a purchase, a cancellation or a support escalation, and those are the questions worth asking about a phone system.

This guide covers the managed path with Airbyte. It is a small, straightforward connector, and the two things worth thinking about before you build are what the credential can reach and what the start date actually bounds.

Aircall to BigQuery at a glance:

Why move data from Aircall to BigQuery?

Two situations account for most of these pipelines.

The first is joining calls to outcomes. Call volume next to CRM records tells you whether phone contact correlates with closing, and next to support tickets whether it reduces or duplicates other channels. Aircall reports activity and cannot report consequence.

The second is operational analysis over a long window: call patterns by hour and team, whether staffing matches demand, how handling time has moved across quarters. If you only need this week's queue statistics, Aircall's own dashboard already shows them.

What do you need before you start?

Short list, and one item is worth raising with whoever owns access rather than quietly configuring:

An API identifier and token. Created together as an API key in your Aircall dashboard under the integrations settings. The token acts as a bearer token, and the connector needs both halves. The Aircall source documentation points to where they live.

Awareness that the key is not scoped. An Aircall API key has read access to all of your company's data, and there is no narrower option to choose. That is a fact about Aircall rather than the connector, and it is worth stating when you request one.

A start date. Described as a date filter for eligible streams, which is a precise phrase worth reading twice. It bounds the streams that support filtering by date rather than everything you select, as covered below.

A BigQuery service account and dataset. With the BigQuery User and BigQuery Data Editor roles. Use a dataset dedicated to this source, because call records identify people and will want their own access controls.

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 an Aircall to BigQuery pipeline in Airbyte?

Step 1: Agree what lands and who sees it

Decide with whoever owns privacy which streams you actually need and who will be able to query them. Call records carry customer phone numbers and identify which employee handled what, so this is a governance decision at the start rather than a cleanup exercise once somebody notices.

Step 2: Configure the Aircall source

Click Sources in the left navigation, then New Source, and select Aircall, following adding a source. Enter the API identifier, the API token and a start date, then run the connection test. This is one of the shorter configurations in the catalogue.

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 ample, because call metadata is small by warehouse standards even across years.

Step 4: Take the reference streams alongside calls

Click Connections, then New connection, and select streams with a sync mode each. Calls and contacts carry the activity. Users, teams, numbers and tags are the reference data that turns identifiers into names, and without them your dashboards show call counts against numeric agent identifiers.

Daily is a sensible cadence. Call data settles quickly, and the reference streams change at the pace of somebody adding a team member or creating a tag, so there is nothing to gain from syncing more often.

Why is the credential more powerful than you would like?

Because Aircall's API keys are not scoped. A key has read access to all of your company's data, and there is no option to restrict it to particular streams, teams or numbers. Whatever you actually sync, the credential itself could read everything.

That is not unusual among smaller SaaS products and it is worth naming rather than glossing over, because a security review will find it and it is better coming from you. It also means the usual mitigations sit outside Aircall: store the key properly, create one dedicated to this pipeline so it can be revoked without affecting anything else, and know who has it.

The related point is what the data contains. Call records identify customers by phone number and employees by name, so the destination inherits a privacy obligation the moment it lands. A dedicated dataset with deliberate grants and an agreed retention period covers most of that, and aggregated views cover most of the analysis without exposing individual calls.

What does the start date actually bound?

Eligible streams, which is the connector's own careful wording. The start date filters the streams that support date filtering, and the others are unaffected by it.

In practice that division follows the shape of the data. Calls and contacts accumulate over time and can sensibly be bounded by a date. Users, teams, numbers and tags describe how your Aircall account is configured right now, and a date filter on them would mean very little, so they come in full regardless of what you set.

This is mostly harmless, because the configuration streams are small. It is worth knowing when a first sync returns more than you expected, since the instinct is to assume the start date was ignored rather than that it never applied to those streams in the first place.

Frequently asked questions

Can I restrict what the Aircall API key can read?

No. An Aircall API key has read access to all of your company's data. Create one dedicated to this pipeline so it can be revoked independently, and handle it accordingly.

Why did some streams ignore my start date?

It is a date filter for eligible streams rather than a global bound. Configuration streams such as users, teams, numbers and tags are not filtered by it.

Which streams are available?

Calls, contacts, company, numbers, tags, teams, users, user availability and webhooks. Take the reference streams alongside calls so identifiers resolve to names.

Which API version does the connector use?

Version 1 by default, which is what the Aircall API offers at present.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven. You will want BigQuery views joining calls to users and teams, and aggregated views so most analysis does not need individual call records.

Get your Aircall data into BigQuery

Create a dedicated API key and be upfront that it is unscoped, agree who can query call records before they land, take the reference streams so your dashboards show names, and expect the configuration streams to arrive in full regardless of the start date.

Airbyte's connector catalog includes 600+ pre-built connectors, so call activity can sit beside the CRM and support data that explains it. For the support side, see Zendesk Support to BigQuery, and for another source carrying recorded customer conversations, Gong to BigQuery.

Start syncing now →