Solved

Serious issue in "List Events" endpoint: "page_token" is not working

  • 6 February 2024
  • 6 replies
  • 127 views

Hello Calendly Developer Community,

I'm encountering a critical issue with the "List Events" endpoint in the Calendly API, specifically related to the pagination functionality. I'm hoping to get some insights or assistance from the community.

Here's a detailed description of the problem:

  • Initial Request Success: The first API call to the "List Events" endpoint to retrieve 100 events works as expected.
  • Pagination Issue: However, when I attempt to make a subsequent call using the page_token parameter (which I received from the initial request) for the next set of events, the API returns a 400 error. This suggests a problem with the pagination implementation.
  • Environment: I've encountered this issue consistently in both Python and Make (Integromat) environments.
  • Comparison with Other Endpoints: To isolate the problem, I've tested pagination with other endpoints, such as the one used for routing forms, and it worked correctly there. This indicates that the issue seems specific to the "List Events" endpoint.

Has anyone else experienced this problem? Any advice or guidance on how to resolve or work around this issue would be greatly appreciated. If additional technical details are needed for troubleshooting, I'm happy to provide them.

Thank you in advance for your help and insights!
Here is python code↓

def get_calendly_events():
base_url = "https://api.calendly.com/scheduled_events"
params = {
"count": 100,
"organization": "https://api.calendly.com/organizations/EHEAVSKRBRWALXMU",
"max_start_time": "2024-02-07T23:30:00Z",
"min_start_time": "2023-09-14T13:16:00Z"
}
headers = {
'Authorization': f'Bearer {token}' # Replace with your access token
}

events = []
# i = 0
while True:
response = requests.get(base_url, headers=headers, params=params)
response.raise_for_status() # Will raise an exception for HTTP errors
data = response.json()
filtered_data = filter(lambda x: x['event_type'] == target_event_type,data.get('collection', []))
if filtered_data:
events.extend(filtered_data)

next_page_token = data.get('pagination', {}).get('next_page_token')
pprint(data.get('pagination', {}))
if not next_page_token:
break
# if i == 0:
# del params['min_start_time']
sleep(0.15)
params['page_token'] = next_page_token
# i+=1

return events


Here is the pic of the predefined backend request of Make module failing.

 

icon

Best answer by AlterCall30248 8 February 2024, 09:48

View original

6 replies

Userlevel 2

@AlterCall30248 Thank you for the detailed information. I don’t have access to Make at the moment to give it shot there but, I tried using Postman to try and I was able to make the PageToken work as expected. Below is the screen shot of my Postman test where I used the token I received from my previous call. I didn’t use start/end time so I can get enough responses for pagination. 

I will let others comment here as well to give their thoughts. It is definitely odd to have the issue on just this endpoint. I will see if I can get access to Make. 

 

 

@Niraj 
Thanks for your response.
I can confirm that it does work when I don’t use `min_start_time` param.
I tried removing that param from the second call already, but it didn’t work either.
Usually other APIs expect the same parameters as the first.

Since we are selling consulting/tranning calls to individuals, there are tons of events.
I really want to have a threshold for this.

Best if we could query events for a specific event type, though.

Userlevel 2

hmm.. that is odd. 
I tried using min/max and token, I am still able to get the results as expected. See my postman screenshot below.

Do you mind sending an email to our dev support [support+developer@calendly.com] team? They can probably see something I am not seeing.
 

 

@Niraj 
I will.
On my end, the result is the same on Postman. I tried the count 25 as well. Only remainig difference I can see is the user vs organization.
 

 

Userlevel 2

So weird. Thank you for reach out to the support directly. Hopefully, they will be able to replicate and figure out what is going on. Sorry about the trouble.

Calendly's technical support advised me to add more zeros which did work:2023-09-14T13:16:00.000000Z

Come to think of it, this format is the standard that the Calendly API expects.
Interestingly, the API appears to be flexible with the format during the initial request, but requires this more precise format for subsequent requests.

Reply