I'm not receiving the Retry After header from the MS Graph API when I get throttled (ie. 429 errors). I also created an issue on github repo for the javascript client library, but this probably isn't an issue with the library. Not sure how to debug this...
The Excel REST API is implemented by SharePoint in the case of a SharePoint hosted file.
The SharePoint REST API sends 503's and not 429's when throttling and doesn't support the retry-after header.
Only OneDrive and Exchange API's support retry after as far as I know. (Having an issue with Exchange ATM though)
(AAD also seems to have implemented the limitations, but it's not clear if it implements retry-after or not)
I added a uservoice comment about that, upvote it to help :) (still under validation, might take a couple of hours to appear)
I found that when querying SharePoint lists and libraries through the Graph API, if you hit SharePoint throttling limits then the Graph does return 429 with no retry info in the headers. That's the short answer, here's a much longer post I wrote about this https://camerondwyer.wordpress.com/2018/01/31/microsoft-graph-api-throttling-sharepoint-lists-libraries-http-429-error-code/
Related
I am trying to configure a mailbox on Exchange Online to be used by our Deskpro ticketing system to manage several queues. The only way I could setup Deskpro to recognise different folders in the mailbox was to make the connection using EWS. MS said they would be deprecating EWS Basic Auth in October last year, does that mean my EWS connection via outlook.office365.com/EWS/Exchange.asmx is now authenticating through OAuth? It still works, I'm concerned MS will change something and it'll stop working.
I'd love to use the OAuth via Graph, but if I select that option in the Deskpro setup there's no way to identify individual folders for each queue to process meaning I'd have to have a separate mailbox for each queue requiring an Exchange Plan license for each!
Collin, yes there is an announcement made to deprecate EWS Basic auth (it was made quite some time earlier too) and move to modern auth/oAuth too - it will work for you. Also you know that no new investments are going to be made in EWS, so you wont get any new features. So keeping in that mind, you can use EWS modern auth/oAuth for a while, but i would recommend you to create plan to move to Microsoft Graph API - so that you can interact with all the existing features in EWS and connect with entire Microsoft Graph ecosystem's product/solutions as well.
Currently we are using EWS API with basic authentication to automate CRUD activities for outlook tasks and calendar items. NOT outlook mail (sending/retrieving messages/mails etc.)
Looking at the notice where the basic authentication will stop working by October 2020, i have started to explore the alternative which is moving to Microsoft Graph API.
But i noticed, there is not yet CRUD for tasks and calendar items under Outlook Mail.
I found the below while googling but seems is not working.
POST https://graph.microsoft.com/beta/me/outlook/tasks
POST https://graph.microsoft.com/v1.0/me/events
My question is, will the EWS with basic authentication affect the Outlook tasks and calendar events as well?
Why i don't see them in the Graph API explorer? they should be under Outlook Mail
I appreciate if you guys can give me insight
Thanks,
Adam
The authentication changes for EWS will impact all the API endpoints available under it on exchange online.
You can find documentation about CRUD operation for Outlook tasks here.
For the graph explorer make sure you click on "show more samples" in the bottom left corner to see everything.
For the events you have the right endpoint, you should switch to a get request to obtain them and check that you requested the proper permissions.
I want to checkout/checkin a file on my OneDrive for Business using Microsoft Graph Client Library, I see the api calls for checkin/checkout
https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/driveitem_checkin
https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/driveitem_checkout
But I am unable to find a way to do the same via the library.
As Michael Mainer posted in comments, the latest Microsoft Graph client libraries just support the version 1.0 of the APIs. Meanwhile the API endpoint for check in file and check out file is only available on the beta.
If we want use these APIs, we can only complete the HTTP request by ourselves.
For more detail, you can find it in the issue on the GitHub.
According to https://products.office.com/en-us/government/compare-office-365-government-plans, the US gov version of office365 is in a segmented cloud, and i found an old SO question suggesting a possible issue regarding management API specifically Support US Government for Office 365 Management API
Does anyone know whether the API gateways such as graph.microsoft.com outlook.office.com/api, manage.office.com/api, as well as the ones for OneDrive/SharePoint etc. are expected to work normally with office365 gov?
Sorry for the delayed response. We just updated out documentation on this. These APIs should work for Office APIS through Microsoft Graph (for the most part). See https://developer.microsoft.com/en-us/graph/docs/concepts/deployments.
Hope this helps,
I am building a web application that needs to fetch all tasks from an organization that uses Outlook Task. Can this be done with Microsoft Graph or Office 365 REST API?
I haven't found any calls in the documentation of either services that would do something similar to that: https://outlook.office.com/api/v2.0/tenant/tasks
Should I find another approach or is it something that is doable?
Outlook Tasks is available in Preview on Microsoft Graph today:
GET /users/{id|userPrincipalName}/outlook/tasks (Graph Explorer example)
I'm afraid I don't have an ETA for when this will be generally available at the moment. According to the Change Log this functionality was added in April so it is still a somewhat recent addition.
This functionality is also available as part of the Office 365 REST API.
If you're looking for something production ready today, you may need to use this API instead. If possible, I would suggest waiting for Graph. Graph is where all future engineering energy will be focused and is the best long-term integration play.