Skip to main content
Question

Calendly Scheduling API returns HTTP 200 with error & shifting available slots on retry

  • December 16, 2025
  • 3 replies
  • 62 views
A

We are integrating the Calendly Scheduling API with our agentic system and are facing unexpected behavior while booking meetings.

Request Payload

{

"date": "2025-12-19",

"time": "02:00",

"email": " [removed by moderator] ",

"name": "name"

}

Response Received

  • HTTP Status: 200

  • Response Body:

{

"status": "error",

"message": "I encountered a system error while booking. I will have a specialist call you to confirm.",

"meeting_url": "",

"scheduled_time": ""

}

We are unsure why the API returns HTTP 200 while the response body indicates an error.

Slot Availability Issue

When testing different times:

  • Request with time = 06:00 returns: “The slot is not available, you can book a slot from the 06:30, 07:00, 07:30”

  • Retrying with time = 06:30 returns: “The slot is not available, you can book a slot from the 07:00, 07:30, 08:00”

Each retry shifts the suggested availability forward, even though we are selecting from the suggested slots.

Expected Behavior

Our logic is:

  1. If the requested slot is unavailable

  2. Fetch the next 3 available slots

  3. Suggest those slots to the user

However, the availability window appears to change with each request.

Questions

  1. Why does Calendly return HTTP 200 with a logical error in the response body?

  2. Is this behavior related to timezone handling, minimum scheduling notice, or buffer rules?

  3. Should availability be re-fetched on every retry, or cached?

  4. Is there a recommended approach to consistently retrieve and lock the next available slots?

Any guidance or best practices would be greatly appreciated.

3 replies

Cameron
Employee
  • Cameron
  • Employee
  • May 28, 2026

Hey ​@Abhay_zenwork - thanks for reaching out with those details!

Looking at your request and the response, neither seem to match the normal shape of Calendly’s public Scheduling API. This strongly suggests there is another layer in front of Calendly — such as a wrapper, middleware service, orchestration layer, or even your AI agent itself — that is returning HTTP 200 with an application-level error body.

In Calendly’s scheduling flow, the pattern would be:

  1. Fetch available times
  2. Submit the selected slot to the booking endpoint with the exact event type and start time

The times returned by our List Event Type Available Times endpoint are a snapshot of live availability, rather than a temporary hold on those times. Because of that, a slot that was valid a moment earlier can be invalid by the time the booking request is made. When that happens, the right behavior is to fetch fresh availability and show updated options rather than retrying against the original times.

This could also explain why the suggested times appear to shift forward on retry. Availability is being recalculated each time against the current scheduling rules, existing conflicts, notice windows, and any routing or fairness logic that applies to that event.

With all of that said, if you share the exact endpoint being called, it should be possible to confirm pretty quickly whether this is a direct Calendly API call or a response being transformed by another layer in your integration.

Thanks!

A
  • Abhay_zenwork
  • Author
  • Community Member
  • May 29, 2026

Thanks ​@Cameron . 

We actually managed to track down and resolve the issue ourselves... sometime during the last 5 months 😄

That said, your explanation does align with what we eventually found regarding live availability and slot validation. Hopefully it'll help the next person who lands here before half a year passes 😉...

A
  • Abhay_zenwork
  • Author
  • Community Member
  • May 29, 2026

Hey ​@Abhay_zenwork - thanks for reaching out with those details!

Looking at your request and the response, neither seem to match the normal shape of Calendly’s public Scheduling API. This strongly suggests there is another layer in front of Calendly — such as a wrapper, middleware service, orchestration layer, or even your AI agent itself — that is returning HTTP 200 with an application-level error body.

In Calendly’s scheduling flow, the pattern would be:

  1. Fetch available times
  2. Submit the selected slot to the booking endpoint with the exact event type and start time

The times returned by our List Event Type Available Times endpoint are a snapshot of live availability, rather than a temporary hold on those times. Because of that, a slot that was valid a moment earlier can be invalid by the time the booking request is made. When that happens, the right behavior is to fetch fresh availability and show updated options rather than retrying against the original times.

This could also explain why the suggested times appear to shift forward on retry. Availability is being recalculated each time against the current scheduling rules, existing conflicts, notice windows, and any routing or fairness logic that applies to that event.

With all of that said, if you share the exact endpoint being called, it should be possible to confirm pretty quickly whether this is a direct Calendly API call or a response being transformed by another layer in your integration.

Thanks!

We actually managed to track down and resolve the issue ourselves... sometime during the last 5 months 😄

That said, your explanation does align with what we eventually found regarding live availability and slot validation. Hopefully it'll help the next person who lands here before half a year passes 😉

Enroll in Calendly’s Research Community” style= Need Help? Visit 'Get Help. Give Help.'
Terms & ConditionsAccessibility statement