Microsoft Loop: under the hood

Warning: The APIs explained in this article are not official documentation and should not be used in any way. This article is for informational purposes only and aims to provide insights into how Microsoft Loop technologies work under the hood.

It is important to note that using unofficial APIs can be risky and may result in security vulnerabilities or unexpected behavior. If you plan to automate your Microsoft Loop tasks using APIs, it is highly advisable to wait for the official documentation to be published.

As a curious technologist, I love to take a peek under the hood of new technologies to understand how they work. Recently, I had the opportunity to explore Microsoft Loop, a powerful tool for that bringing together teams, content, and tasks across tools and devices that is built on top of Microsoft Fluid.

While exploring Microsoft Loop, I was curious about how the various APIs communicate with each other to display the data that users see on their screens. By diving into the underlying APIs, I was able to gain a deeper understanding of how Microsoft Loop functions and the technologies that power it. In this article, I will share my findings and provide insights into how Microsoft Loop uses APIs to manage data.


When users authenticate with Microsoft Loop, the authentication happens against the Chapter 5 Fluid App with the ID a187e399-0c36-4b98-8f04-1edc167a0996 and with the scope openid profile offline_access, which makes the audience in your JWT token.

To ensure the security of the authentication process, Microsoft Loop uses the Authorization Code flow with PKCE (Proof Key for Code Exchange). This is a robust authentication process that helps prevent code injection attack.

As a technology enthousiast, I was intrigued by the authentication process used by Microsoft Loop and decided to try to mimic the authentication flow to see if I could get an access token out of it. However, I quickly ran into walls, which is a testament to the strong security measures put in place by Microsoft.

While it may be frustrating to be unable to replicate the authentication flow, this is actually a good thing. It means that the authentication process used by Microsoft Loop is well put together in terms of security, and that users can trust that their data is protected.


Since the authentication part didn’t success in getting me an access token, I took the active access token from my active Microsoft Loop session. Which isn’t a best practice but like I said, this is for informational purposes only. So with this access token I was able to run some endpoints against workspaces

The Microsoft Loop endpoints currently work on Microsoft 365 substrate which plays a crucial role in facilitating services that operate across various applications, including Exchange Online, SharePoint Online, Teams, and others. You could say that the Substrate servers as the operating system for Microsoft Cloud

Get your loopcomponents


Here I was pleasantly surprised that there is an API with which you can query all loop components. For example, with this api I got back all workspaces as well as all pages that fall under a certain workspace. The nice thing here is that you also get all deleted pages back with of course the “isDeleted” property set to true

Create a workspace

Creating a workspace seemed quite simple at first. Soon I found an api that did this through a post request with a body. But it turned out not to have the effect I expected because my workspace turned out not to have been created.

When I looked closely, it turned out that immediately after creating the workspace another api was executed to an inaccessible site collection. This api gave a long body describing the page in json format. I also noticed that this uses a fluid session ID and a container ID. The container ID is something that should match the container you pass in your page’s json while the fluid session id should match the session id that is currently active on the server.



     "enabledWorkloads": ["SharePoint"],

Rename a workspace

To rename a workspace, the process is quite simple. A PATCH request needs to be performed to a specific URL, with the new title specified in the request body. Notably, the URL includes a unique identifier, which consists of a prefix (OID) followed by two separate GUIDs, separated by an @ symbol.


Delete a workspace

deleting a workspace is pretty straightforward too, by doing a DELETE to the same api you use to rename a workspace



In conclusion, while it can be tempting to explore and experiment with unofficial APIs to gain a deeper understanding of new technologies like Microsoft Loop, it is important to exercise caution. The APIs discussed in this article should not be used to automate any processes, as doing so can pose security risks and result in unexpected behavior. Instead, it is advisable to wait for the official documentation to be released before attempting to automate tasks using APIs.

The apis currently being used in the public preview may give an indication of the direction the official apis will go in the future.

Altogether, the operation under the hood of the public preview of Microsoft Loop is well put together and some thought has been given to how certain things work. Creating a workspace is quite complex and I hope that this can be done in a simpler way once the official APIs are out.

Blog at

%d bloggers like this: