> 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/time-tracking/cal-com/best-practices.md).

# Best Practices

## Recommended setup

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Start with Bookings + Event types</strong></td><td>These two entities together give you the most actionable data. Join them on `event_type_id` to see not just what meetings happened, but which templates they came from — useful for spotting which meeting types are most in demand.</td></tr><tr><td><strong>Use Append for multi-user setups</strong></td><td>Since Cal.com API keys are scoped per user, create one data flow per team member and use the Append transformation to merge all bookings into a single table. Add a custom column for each user's name before appending so you can filter by person later.</td></tr><tr><td><strong>Send to BigQuery for team reporting</strong></td><td>If you're aggregating bookings across multiple users or time periods, BigQuery handles large volumes better than Google Sheets. Use Coupler.io's Aggregate transformation to pre-compute booking counts or durations before loading.</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>Daily refresh is usually enough</strong></td><td>Booking data doesn't change in real time for most reporting needs. A daily scheduled run keeps your dashboards fresh without hammering the Cal.com API. Run the data flow manually first to confirm it's working before setting a schedule.</td></tr><tr><td><strong>Schedule staggered runs for multi-user flows</strong></td><td>If you have multiple data flows (one per team member), stagger their run times by a few minutes to avoid hitting Cal.com's rate limits simultaneously.</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>Only pull the entities you need</strong></td><td>Entities like Conferencings and My profiles rarely change — pull them once to reference, but don't include them in high-frequency scheduled flows. Focus recurring runs on Bookings where the data is actively updated.</td></tr><tr><td><strong>Use AI destinations for meeting summaries</strong></td><td>Pipe your Bookings data to ChatGPT, Claude, or Gemini to generate weekly meeting summaries, flag unusual cancellation patterns, or draft follow-up templates based on attendee responses.</td></tr></tbody></table>

## Common pitfalls

{% hint style="danger" %}
Don't assume one API key covers your whole team. Cal.com API keys are tied to individual user accounts — using one person's key will silently exclude all other users' bookings from your reports.
{% endhint %}

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

* Join Bookings with Event types to add context to each meeting
* Add a `user` identifier column when appending data from multiple accounts
* Verify your timezone settings in Schedules match the timezone in your reporting tool
  {% endcolumn %}

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

* Rely on booking counts alone — always check the `status` field to exclude pending or cancelled records
* Pull Conferencings or Schedules on every refresh — these change infrequently and don't need daily syncing
* Ignore the `uid` field — use it as a stable unique key when setting up incremental loads or deduplication in your destination
  {% 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.coupler.io/sources/category/time-tracking/cal-com/best-practices.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.