Tavily Web Search MCP Server

<img src="https://r2cdn.perplexity.ai/pplx-full-logo-primary-dark%402x.png" class="logo" width="120"/> ## Known Issues with Cal.com API Returning `no_available_users_found_error` Despite UI Availability The error message: ``` ❌ Error creating appointment: 400 Client Error: Bad Request for url: https://api.cal.com/v1/bookings?apiKey=... Response JSON: {'message': 'no_available_users_found_error', 'data': None} ``` is a **well-documented and recurring issue** with Cal.com API bookings, even when the UI shows the slot as available for the user. --- **Key Findings from User Reports and Community Discussions** - **Error Meaning**: The `no_available_users_found_error` does not always mean the user is unavailable. It is a generic error that can be triggered by several underlying causes, some of which are not reflected in the UI[^1][^2][^3][^4]. ### Common Causes Identified - **Booking Outside Defined Availability**: Attempting to book outside the user's or team's defined availability window can trigger this error, even if the UI appears to show the slot as open[^2]. - **Booking Limits Exceeded**: If the user or team has set limits (e.g., maximum bookings per day/week/month), exceeding these limits will cause this error—even if the slot appears available[^2]. - **Incorrect or Incomplete Payload**: Issues with the API request body, especially with the `location` field, can cause this error. For example, specifying a `location` value incorrectly (such as using a string like "Zoom" or "Google Meet" instead of the required structure) can result in the error, regardless of actual availability[^4]. - **Time Formatting Issues**: Incorrect time formats or time zones in the API payload may cause the backend to interpret the booking as invalid or in the past, leading to this error[^5]. - **Staging vs. Production Differences**: Some users report that bookings succeed in staging but fail in production, suggesting possible configuration differences or caching issues[^3]. - **API/Backend Bugs**: There are reports and acknowledgments from the community that this error can sometimes be a bug, where the actual cause is not communicated accurately by the error message[^2][^3]. --- ### Example User Experiences - **GitHub Issues and Discussions**: Multiple users have confirmed that they receive this error even when all parameters (user ID, event type ID, time slot) are correct and the slot is open in the UI[^1][^3]. - **Make.com Community**: Users automating bookings via Make.com also encounter this error, even after verifying all parameters. The error persists until the API payload is adjusted, especially the `location` field[^6][^4]. - **YouTube Walkthroughs**: Video guides confirm that incorrect formatting of the `location` field is a frequent cause, and that leaving `location.value` and `location.optionValue` as empty strings often resolves the issue[^4]. --- ## Troubleshooting Steps If you encounter this error despite UI availability, try the following: - **Double-check booking limits** for the user or team (daily, weekly, monthly caps)[^2]. - **Verify the API payload**: - Ensure the `location` field is structured as required (often both `value` and `optionValue` should be empty strings unless specifically needed)[^4]. - Confirm that the `start` and `end` times are in the correct ISO 8601 format and match the user's time zone[^5]. - **Test with minimal required fields** to rule out custom fields or optional parameters as the cause[^4]. - **Compare staging and production settings** for discrepancies if bookings work in one but not the other[^3]. - **Review Cal.com documentation and recent bug reports** for updates or known issues with the API[^3][^4]. --- ## Summary Table: Common Causes vs. Solutions | Cause | Solution/Check | | :-- | :-- | | Booking outside defined availability | Confirm user's calendar and event type availability | | Booking limits exceeded | Check and adjust user/team booking limits | | Incorrect `location` field | Use `{ "value": "", "optionValue": "" }` if unsure | | Time formatting issues | Use correct ISO 8601 format and ensure time zone matches | | Staging/production config differences | Align settings and clear caches | | API/backend bug | Monitor GitHub/issues, report to Cal.com if persistent | --- ## Conclusion Yes, there are **known and recurring issues** with Cal.com API calls returning the `no_available_users_found_error` even when the UI shows the slot as available. The causes range from booking limits, payload formatting (especially the `location` field), and time formatting issues, to possible backend bugs. Double-checking your API request structure and reviewing booking limits are the most effective first steps to resolve this error[^1][^2][^6][^3][^4]. <div style="text-align: center">⁂</div> [^1]: https://github.com/calcom/cal.com/discussions/16173 [^2]: https://github.com/calcom/cal.com/discussions/18410 [^3]: https://github.com/calcom/cal.com/issues/17535 [^4]: https://www.youtube.com/watch?v=RrPvEq4ZuWQ [^5]: https://community.make.com/t/error-400-bad-request-message-no-available-users-found-error/64248 [^6]: https://community.make.com/t/stuck-on-a-400-error-with-cal-com-integration/71075 [^7]: https://cal-docs.motif.land/docs/enterprise-features/api/api-reference/availabilities [^8]: https://community.calendly.com/api-webhook-help-61/400-error-invalid-parameter-on-organization-yet-organization-is-required-4099 [^9]: https://cal.com/docs/api-reference/v2/bookings/get-a-booking [^10]: https://community.n8n.io/t/cal-com-get-slots-call-returns-400-when-used-with-api-key-but-if-passed-as-header-parameter-it-works-any-one-knows-why/94342