0
votes

I am trying to get both personal calendar and shared calendar in an office 365 account using RESTapi. Since currently Oauth2 doesn't support accessing shared calendar, I'm testing my code with basic authorization.

I have three calendars in my account:

  1. [email protected](own calendar)
  2. [email protected](shared calendar)
  3. [email protected](shared calendar)

Using following end points I was able to get events using basic authorization:

https://outlook.office365.com/ews/odata/Users('[email protected]')/Events

The strange part is for the past two days I'm not able to get events for [email protected] and [email protected] using the same end point. I get the following error when I try to access the events:

{"@odata.context":"https://outlook.office365.com/ews/odata/$metadata#Users('[email protected]')/Events","value":[{"error":{"code":"ErrorInternalServerError","message":"Object reference not set to an instance of an object."}}

But I can still access events for [email protected] using same endpoint and basic authentication.

I also tried to access own calendar using oauth2. I get similar error

{"value":[{"error":{"code":"ErrorInternalServerError","message":"Object reference not set to an instance of an object."}}

But I can successfully talk to calendar endpoint

I was wondering if anyone had seen this error before. Any help/suggestions are greatly appreciated.

3

3 Answers

2
votes

Using Basic authentication isn't recommended, and isn't supported for production use. Basic is there for now to ease exploration of the API, but will be deactivated at some point in the future.

With that being said, you said that you get the error when you access your own calendar using OAuth2, is that right? This sounds like it might be an intermittent issue, but there's not really enough information to know exactly what's happening. If you're still seeing it, it would be good to add instrumentation headers to your requests (User-Agent, client-request-id, return-client-request-id) and get a network trace of the request response.

1
votes

In addition to Jason's comments, please use our production endpoint https://outlook.office.com/api/v1.0 instead of our old preview endpoint https://outlook.office365.com/ews/odata/ See this blog post for more details.

0
votes

This confused me too. Everything on the web will point you to using the Office 365 API, but trust me, that's not what you will want to do. You will want to use the Exchange API. Office 365 just IS an Exchange server so you can automate it in the same way you can automate any Exchange server. There is sample code here. It is very simple.

Consume Office 365 REST API Without UI

The Office 365 API is just a set of tools for buildings UI based apps that allow the user to enter their Office 365 credentials and allow the app to work on their behalf.