Calendar Get Request Resulting in a 503 Error when "calendarview" is set to a Large Time Interval

Gabriel Pillay 61 Reputation points

I hope you are well.

Any insights into this problem would be appreciated.

I am trying to GET calendar events of various employees over a large specified time interval. This is implemented using MS graph api and an endpoint consisting of a calendar ID with a calendarview parameter. The time interval extends into the future.

When I initialise this time interval sufficiently small <500 days, I get results as expected. But for calendarview intervals beyond 500 days, I receive a 503 error for one particular employee (employee A). Over many trial and error iterations, I occasionally get this error for another particular employee (employee B).

I believe employees A and B have the most events in their calendars. I add '&%24top=1024' at the end of the endpoint to GET a large number of events per calendar. I have saved up to 1000 events from employee B but not even 600 from employee A. (my for loop processes employee B before employee A)

The 503 error occurs seemingly inconsistently, I'd like to be able to predict it.

What could be the cause of this issue? What could be limiting this large request? Will it ever occur for smaller time intervals?

Have a great day,
Gabriel Pillay

Microsoft Graph
Microsoft Graph
A Microsoft programmability model that exposes REST APIs and client libraries to access data on Microsoft 365 services.
11,382 questions
0 comments No comments
{count} votes

Accepted answer
  1. Shivam Dhiman 5,951 Reputation points

    Hi @Gabriel Pillay

    Error 503 comes when 'The service is temporarily unavailable for maintenance or is overloaded. You may repeat the request after a delay, the length of which may be specified in a Retry-After header'. Refer this documentation. You can retry the requests or increasing the timeout (Incase you are using any custom application increase the timeout for at least 2 min).

    Another reason could be likely because the services are busy. You should employ a back-off strategy similar to 429. Additionally, you should always make new retry requests over a new HTTP connection. Refer this documentation.

    By default, you're limited to 10 items in the response. You should also see in your response an @odata.nextLink, which is the URL you can use to request the next page of results (again, 10 being the default page size). You can increase your page size by using the $top parameter, up to a maximum of 1000 (IIRC). Refer this document: List CalendarView.

    Best Practices while using CalendarView:
    • The recommended time window used in the CalendarView should ideally be not more than one week. This is because CalendarView API does a lot of processing in the backend before providing the results.
    • Using $skip and/or $top in the API query parameters doesn't necessarily skip the calculations needed for getting the results for this API. Hence, if a larger window of CalendarView is to be queried, the client should make CalendarView API calls with different time windows, rather then using a larger time window and relying on $skip and $top.
    • Server side time limit for getting the results of any REST API is 2 minutes (120 seconds), after which the API request gets terminated and the client will receive a 500 Status Code. On observing such long delays, the client should reduce the time window being queried for and try again.
    • The $select on the API should preferably contain only on-page properties
    Example : $select=Id,ChangeKey,Categories,OriginalStartTimeZone,OriginalEndTimeZone,iCalUId,
    You could exclude properties you dont need for faster responses.
    • If the time window has numerous recurring series events, CalendarView needs to load all the instances in that time frame which makes it less performant.

    Hope this helps.

    If the answer is helpful, please click Accept Answer and kindly upvote. If you have any further questions about this answer, please click Comment.

    1 person found this answer helpful.
    0 comments No comments

0 additional answers

Sort by: Most helpful