> For the complete documentation index, see [llms.txt](https://docs.coupler.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coupler.io/sources/category/sales/aircall/best-practices.md).

# Aircall Best Practices

Optimize Aircall imports by starting with calls data, setting smart date filters, and avoiding historical data overload.

## Recommended setup

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Start with Calls</strong></td><td>The Calls entity contains the richest data in Aircall. Set this up first to validate your connection and get immediate value before adding other entities.</td></tr><tr><td><strong>Set a sensible start date</strong></td><td>Use the date picker to limit your import to the period you actually need. Pulling years of data on the first run slows things down and fills your destination with records you may not use.</td></tr><tr><td><strong>Label your data flows clearly</strong></td><td>Name each data flow with the entity and destination, for example "Aircall – Calls – BigQuery". This saves time when you're managing multiple connections.</td></tr></tbody></table>

## Data refresh and scheduling

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Schedule Calls data flows frequently</strong></td><td>Call data changes constantly. A refresh interval of every 1–4 hours keeps your dashboards current without hammering the API.</td></tr><tr><td><strong>Refresh Users and Teams less often</strong></td><td>Team structure and user profiles change infrequently. A daily or weekly refresh is usually enough for these entities.</td></tr></tbody></table>

## Performance optimization

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Narrow your date range for large teams</strong></td><td>If your team handles hundreds of calls per day, pulling several months of data at once can slow imports significantly. Start with a rolling 30–90 day window and expand as needed.</td></tr><tr><td><strong>Avoid overlapping schedules</strong></td><td>If you have multiple Aircall data flows, stagger their refresh times by 10–15 minutes. Running them simultaneously can increase the chance of hitting rate limits.</td></tr></tbody></table>

## Common pitfalls

{% hint style="danger" %}
Do not share your Aircall API Token publicly or commit it to version control. Anyone with your API ID and Token can read your call data, contacts, and recordings.
{% endhint %}

{% columns %}
{% column %}
**Do**

* Rotate your API key periodically and update it in Coupler.io
* Use the start date to scope the data flows to the data you need
* Store exported data in a dedicated sheet or table to avoid accidental overwrites
  {% endcolumn %}

{% column %}
**Don't**

* Pull all historical data on every scheduled refresh — use incremental date ranges where possible
* Use an agent-level account for the API connection — you need Admin access
* Rely on the User availabilities entity as a historical log — it reflects the current status only
* Run data flows for every entity at the same time on the same schedule
  {% endcolumn %}
  {% endcolumns %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.coupler.io/sources/category/sales/aircall/best-practices.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.