v2/bookings Response time is to high

[alexcoopper]

Hi all,

I’m using the Platform API to integrate Cal.com into my service. One use case is listing bookings. However, the response time for
https://api.cal.com/v2/bookings?take=10&skip=0&sortStart=asc&status[]=cancelled
is too high—around 5–10 seconds.

Is there a way to improve this? Any recommended optimizations or query parameters to speed this up?

For context, I’m on the free plan during development and plan to switch to Essential when ready—if that would meaningfully improve performance.

[dosubot[bot]]

The main reason for the slow response is that the API scans a large dataset when no date filters are applied, even if you use pagination and status filters. The best way to speed up your /v2/bookings queries is to add date filters to limit the range of bookings returned. For example, you can use afterStart and/or beforeEnd parameters to restrict results to a specific time window (e.g., the last month or a custom range). This dramatically reduces the amount of data the backend needs to process and will improve response times [source].

Switching to the Essential plan is unlikely to make a noticeable difference for this endpoint, since the bottleneck is query complexity and database load, not plan-based prioritization [source].

Recent backend changes have improved indexing and caching for some features, but bookings listing queries are not currently cached, so optimizing your query parameters is the most effective approach [source].

Try adding something like afterStart=2025-07-01T00:00:00Z&beforeEnd=2025-08-01T00:00:00Z to your query string to see faster responses.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[alexcoopper]

@dosu afterStart and/or beforeEnd does not help that much.
The only thing that helped was changing the take parameter to 5, for example. However, it's annoying to fetch 5 items per call.

[dosubot[bot]]

The slow response for larger 'take' values is due to how the API fetches and processes bookings: it uses offset-based pagination and loads related data (like attendees and event info) for each booking, which adds overhead as the number increases. There aren't any undocumented query parameters or plan upgrades that will significantly improve performance for bigger batches—this is a backend/database limitation, not a plan or configuration issue [source].

Supported optimizations are: using both start and end date filters (for example, afterStart + beforeEnd, or past + afterStart) to narrow the query window, and keeping the 'take' value low. If you need more items, batching requests (fetching multiple pages in parallel) is the most practical workaround right now. Significant improvements would require backend changes like cursor-based pagination or more aggressive caching, which aren't currently available [source].

If you want to fetch a wider range, make sure to use one of these filter combinations: past + afterStart, upcoming + beforeEnd, afterStart + beforeEnd, afterCreatedAt + beforeCreatedAt, or afterUpdatedAt + beforeUpdatedAt [source].

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[alexcoopper]

@dosu But on the cal.com site fetching of 50 items takes up to 1 sec. Why can't I achieve the same using an API?

[dosubot[bot]]

The Cal.com web app can fetch bookings much faster than the public API because it uses internal server-side APIs, direct database queries, and feature-flagged caching that aren't available to external API users. The public API endpoint (/v2/bookings) is designed for general, secure access and doesn't benefit from these internal optimizations. It fetches related data (like attendees and event info) for each booking and uses offset-based pagination, which adds overhead and slows down large queries. There are no user-accessible settings or plan upgrades that can bridge this gap right now. Some caching improvements are being developed, but they're not yet available in the public API citation citation.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}