SharePoint Get list fails

"invalid_request" specifically (rather than "invalid_client" or "invalid_grant") often points to the token request itself being malformed or hitting a deprecated/changed endpoint — which lines up with the ACS deprecation possibility above, since old endpoints may now reject requests differently.

Try getting a token manually via Postman or a browser using the same client ID/secret/tenant against the token endpoint. If that also fails, it's confirmed to be Azure AD/SharePoint-side, not your AA360 bot config.

I am currently experiencing the same issue. Our automations that use the SharePoint package have begun failing and giving us the same 401 error.

We are currently creating a new application in microsoft entra that will replace the old client. I will give an update on whether that works for us or not.

​@Uzumaki ​@daniel.violette ​@amankumar236 Try using the Microsoft Graph API setting for the SharePoint: Authenticate action.

We created a new OAuth Connection using Microsoft GraphAPI. Though we are able to connect and extract the list data it is taking much longer to get the data. What was taking about 45 seconds now takes 3 minutes. Any suggestions to reduce this time?

​@daniel.violette Do you want a straight answer, or the funny one.  🤣

The straight answer is to see what the bottleneck is.

• Try using the Microsoft Graph API calls in Postman or Bruno and see if SharePoint is what’s taking so long to respond. 
• Check to see if your network is busy -- maybe try at a different time of day (e.g., morning/evening) when SharePoint and your network is less busy.
• Depending on what you’re receiving, can you get the list from a different folder level that may have fewer nodes? Maybe omit subfolders if possible?

Unfortunately with SharePoint, you’re at your network’s, Microsoft’s servers, and the Internet’s whims for speed. All we can do as developers is to return as little data as possible.

​@daniel.violette and ​@Uzumaki We had the same issue Monday with our SharePoint package as well.  After speaking with Microsoft we were told the following:

“The Azure Access Control Service (ACS) retirement for SharePoint Online (announced a few years ago) took full effect on April 2, 2026.  If your app kept working past that date it was due to a residual condition on our [Microsoft] side that has since been corrected and is now nearly globally deployed, which is why the failures are surfacing now.”

So essentially, over the July 4th weekend Microsoft patched a bug they had found which caused any ACS registered apps that had been still working to fail. 

The options going forward, as was already mentioned, are to either register the app in Microsoft Entra or use Graph API instead.

My org used the information in this article here and it resolved the issue. We reconfigured the application in Azure and the Oauth connection in the control room. Best luck

https://apeople.automationanywhere.com/s/article/A360-SharePoint-Configuration-with-Control-room-OAuth-connection