create share /shares endpoint not respecting host availability

Following up here, I think there’s a bug with the /shares endpoint. 

• When getting a one-time link from the /shares endpoint for a Round Robin Event type assigned to a Team, passing no override values in your request (so just the event URI):
  • Expected behaviour:
    • The host availability in the target Event Type is used for the one-time link obtained from the /shares endpoint. 
  • Actual behaviour:
    • The scheduling link ignores the availability of the target event. 

Here is an image demonstrating the bug in that specific flow. 

• Team event via Calendly web UI (top left)
  • Correct availability
• non-team event via Calendly UI (top right)
  • Correct availability
• Team event via /shares endpoint (bottom left)
  • INCORRECT AVAILABILITY
• non-team event via /shares endpoint. (bottom right)
  • Correct availability

This behaviour is both unexpected, and runs contrary to the documentation for that endpoint. 

I have yet to hear back from Calendly Developer Support about whether this is the intended behaviour or not. 

But if you are using the /shares endpoint for any Team events, this is definitely something to look out for because it has caused us some headaches both with mis-scheduled calls, and dev time investigating this. 

Hopefully this post helps save someone else some time and hair loss!

Under the assumption that the issue lies with Team-assigned event types, I rebuilt all of our round robin event types as not Team assigned (which has several admin disadvantages but is a tradeoff we’d be willing to accept at least in the short term). 

Upon testing these newly-created Event Types, I’m seeing more nonsensical behaviour related to availability. 

I am at an impasse here, and the undocumented and inexplicable behaviour of the /shares endpoint is delaying our ability to ship an update required by our internal partners.

I have been awaiting any response from Calendly Developer Support since Monday, but it’s been silence as of late afternoon Wednesday. 

I look forward to hearing from literally anyone at Calendly who might be able to make sense of this so we can regain confidence and trust in Calendly as vendor and mission critical tool. Right now, that trust is waning rapidly. 

 ​@scottisloud - The documentation mentions that it only works for 1-1 event types; I’m wondering if round robin event types are no longer considered 1-1 now that you can enable multi host RR events.

Could you elaborate on your use case? I’m wondering if the single use links endpoint could be used here since it sounds like you don’t need to override the availability.
 

This feature is only available for one-on-one event types.

Hi Calforce,

You are right, the documentation does say that, and yet when I send a URI for a round robin event, I don’t get an error for an invalid request (which would be my expectation if I sent a request that was not acceptable by an API). I get back a scheduling link for an event Calendly _knows_ is a round robin event. 

So either the API has a bug and is mishandling valid requests with Round Robin links. 

Or the API has a bug because it’s accepting arguments that are invalid and fails to return an error. 

Or there’s some other problem here.