What is SharePoint Embedded? Microsoft’s Modern Path for Embedding 365 Document Editing
For more than a decade, organisations that wanted to embed Microsoft Word, Excel, or PowerPoint editing into their own software had two practical choices: build a WOPI host and join the Cloud Storage Partner Program, or build a thin shim around OneDrive and SharePoint via the Microsoft Graph API. Neither was straightforward. WOPI is technically demanding, requires storing and serving the user’s documents from your own infrastructure, and depends on Microsoft accepting your business into the Cloud Storage Partner Program. A direct OneDrive or SharePoint integration meant exposing your users to the complexity of an existing Microsoft 365 tenant, which is rarely what a software product wants its users to encounter.
In late 2023 Microsoft announced a third option, and across 2024 and 2025 it matured into a production-grade platform service: SharePoint Embedded. By the start of 2026, SharePoint Embedded has become Microsoft’s preferred path for embedding Microsoft 365 document editing into third-party applications — and the strategic centre of gravity in the Microsoft document integration market is shifting accordingly.
This article explains what SharePoint Embedded is, how it differs architecturally from WOPI and from the broader Microsoft 365 platform, the licensing and consumption model, and the situations in which SharePoint Embedded is the right choice. It is the foundational explainer for a practice area McKenna Consultants is investing heavily in alongside our long-standing WOPI and Cloud Storage Partner Program work.
The Problem SharePoint Embedded Solves
Software vendors building line-of-business applications routinely encounter the same product requirement: users want to author and edit Microsoft Office documents inside the application, without exporting files, without launching a separate Office application, and without the application’s identity disappearing as soon as the user lands in a Microsoft user interface.
Three categories of integration historically tried to solve this:
-
Office Online via WOPI. A WOPI host stores the user’s documents in its own infrastructure and exposes them to Office for the web through the WOPI protocol. Your application keeps full ownership of storage, identity, and the user experience around the document. This works extremely well — but it requires building and operating a WOPI host, joining the Cloud Storage Partner Program, and managing the security, scale, and update obligations that go with it.
-
Microsoft Graph against the user’s OneDrive. A simpler model in which the application authorises against the user’s existing Microsoft 365 tenant and reads or writes documents stored there. This requires the user to have a Microsoft 365 tenant, exposes users to its administrative model, and routes document storage through their organisation rather than yours.
-
Local Office automation or commercial conversion libraries. Older approaches relying on server-side Office automation, headless conversion, or third-party rendering libraries. These produce inferior fidelity, do not enable real-time collaboration, and create their own commercial and licensing risks.
SharePoint Embedded is Microsoft’s answer to a clear gap: the Software-as-a-Service application that wants Microsoft 365 document editing as a feature, embedded into its own UI, with its own identity model, but does not want to build and operate a full WOPI host and does not want to depend on each user having an enterprise Microsoft 365 subscription.
What SharePoint Embedded Actually Is
SharePoint Embedded is a Microsoft 365 platform service that exposes the storage, identity, collaboration, and Office editing capabilities of SharePoint and OneDrive as a programmatic surface that third-party applications can consume through the Microsoft Graph API. It is, in plain language, a way to use Microsoft’s storage and Office editing infrastructure inside your own application — without users needing to see SharePoint, without them needing a SharePoint subscription of their own, and without you needing to build a WOPI host.
A few core concepts define the model.
Containers. A container is a SharePoint Embedded storage scope. It is conceptually similar to a SharePoint site or a OneDrive drive, but it is owned by your application — not by an end user or by a customer’s Microsoft 365 tenant administrator. Each container holds files, supports the full Office collaboration feature set (coauthoring, sensitivity labels, version history, retention), and is addressable via Microsoft Graph endpoints. Most applications will create many containers — for example, one per customer organisation, one per project, or one per workspace inside the application.
Container types. A container type is a registered descriptor that tells SharePoint Embedded how a class of containers should behave. Container types are owned by an ISV’s application registration and define the permissions model, the consuming-tenant authorisation flow, and the application-level metadata that governs how containers are created and used. Every container belongs to exactly one container type, and a container type is registered once per ISV per Microsoft 365 tenant model that the application supports.
Microsoft Graph as the API surface. Once a container type is registered and a container is provisioned, all programmatic interaction happens via Microsoft Graph. Listing folders, uploading files, creating subscriptions to change events, launching Office editing — these are all Graph operations. There is no separate SharePoint Embedded API; Microsoft has consciously routed the platform through Graph, so existing investments in Graph clients, SDKs, and tooling carry over directly.
Office editing as a built-in capability. SharePoint Embedded gives you the Office editing experience for free, without you needing to implement WOPI. When a user opens a document from a container, the file is rendered through Office for the web with full coauthoring, sensitivity label enforcement, retention, Microsoft Purview integration, and Copilot capabilities — all exactly as they would behave in a first-class SharePoint or OneDrive context.
Identity isolation. Although containers live in the Microsoft 365 platform, they are not visible inside any consuming organisation’s SharePoint admin centre by default. They are owned by your application and operate under the application’s identity. Consuming tenants can opt to govern your containers through Microsoft Purview if they wish, but the default position is that containers are an extension of your software product, not a part of the customer’s SharePoint estate.
This architecture has a profound implication: an application built on SharePoint Embedded can offer a complete Office editing experience without ever exposing the user to a SharePoint URL, a SharePoint admin centre, or a SharePoint licensing conversation. The user just sees your application — and an Office editing surface that happens to be fully Microsoft-grade.
How SharePoint Embedded Differs from a WOPI Integration
For organisations that already understand WOPI, the contrast is illuminating. The two approaches solve overlapping problems but with very different architectural commitments.
Storage ownership. A WOPI integration stores the user’s documents in your infrastructure. You operate the file store, the backup regime, the compliance posture, and the data residency boundaries. SharePoint Embedded stores documents inside Microsoft’s infrastructure, in a Microsoft-managed region. You retain logical ownership through the container model, but the bytes live in Microsoft’s data centres.
Identity model. WOPI relies on access tokens that your application issues and that the Office client validates via your discovery endpoints and proof key infrastructure. SharePoint Embedded uses Microsoft Entra ID — your application registers in Entra ID, requests delegated or application permissions, and acquires Graph tokens through standard OAuth 2.0 flows. There are no proof keys to rotate.
Operational responsibility. A WOPI host has standing operational obligations: discovery document availability, certificate rotation, proof key validation correctness, conformance with each Microsoft Office update, and 24×7 endpoint reliability. SharePoint Embedded shifts all of this to Microsoft. Your operational responsibility shrinks to your own application code and your own integration with Graph.
Licensing and commercial model. WOPI requires Cloud Storage Partner Program membership, which involves business-level engagement with Microsoft, partner agreements, and (for advanced features) the CSPP Plus tier. SharePoint Embedded uses a consumption-based model — you are billed for storage, transactions, and bandwidth associated with your containers, with no separate partner programme to join. Either model can be cheaper depending on the shape of your business, but the commercial posture is fundamentally different.
Feature surface. Some features still favour each path. WOPI hosts in the CSPP Plus programme can offer backstage integration, geo-fencing under partner control, and chunked file transfer with custom protocols. SharePoint Embedded brings native coauthoring, sensitivity labels, retention, and Microsoft Purview integration without any additional implementation work. Copilot integration is fully supported on both, but the SharePoint Embedded path is more direct because the documents already live inside the Microsoft 365 trust boundary.
We will publish a dedicated decision-framework article comparing SharePoint Embedded and WOPI in detail later in Q2. For now the headline is straightforward: most new entrants should evaluate SharePoint Embedded first; established CSPP partners and applications with hard storage-sovereignty requirements remain firmly in the WOPI camp.
When SharePoint Embedded Is the Right Choice
The strongest cases for SharePoint Embedded share a small set of characteristics.
You are a software vendor, not a storage provider. If your business is selling a SaaS product whose users happen to need to edit Office documents — a project management tool, a contract management platform, a clinical record system, a learning platform — SharePoint Embedded is the natural fit. You do not want to be in the storage business, and SharePoint Embedded means you are not.
You want to sell to customers who do not have or do not use Microsoft 365. SharePoint Embedded does not require your customers to have a Microsoft 365 tenant. The platform is licensed and operated by your application’s Microsoft tenant, and your customers consume it through your software. This is a substantial commercial advantage when targeting markets where Microsoft 365 adoption is not universal or where the customer organisation deliberately keeps software vendors out of its corporate identity boundary.
You want native coauthoring, Copilot, and sensitivity labels with minimal effort. These features are first-class in SharePoint Embedded and require no implementation work. In a custom WOPI host, coauthoring alone is a substantial engineering project, and Copilot integration adds further depth.
You do not have, and do not want to acquire, the operational discipline to run a WOPI host at scale. A high-availability WOPI host has non-trivial requirements around discovery uptime, certificate management, proof key correctness, and Office release tracking. For organisations that would rather invest engineering effort in their core product, SharePoint Embedded is a sensible trade.
You need a quick path to Office editing as a feature in a product that is otherwise unrelated to Microsoft 365. SharePoint Embedded is the fastest credible route from “we want Office editing” to “Office editing works in our product.”
When WOPI Remains the Right Choice
SharePoint Embedded is not the right answer for every organisation, and we say so consistently. The cases where WOPI continues to win are clear:
- Established Cloud Storage Partner Program members who have built their value proposition around being a customer-facing storage location inside Office. The CSPP partner journey, especially in the CSPP Plus tier, has features (notably backstage integration into the Office File menu) that SharePoint Embedded does not replicate.
- Applications with hard storage-sovereignty requirements that are difficult to meet inside Microsoft’s managed regions — for example, regulated environments where data must remain in a specific national jurisdiction outside Microsoft’s available regions, or in a customer-controlled storage layer.
- Applications where the storage layer itself is the product. Document management systems, enterprise content management vendors, and cloud storage businesses are not the right candidates for SharePoint Embedded — their value proposition is the storage, and giving it up to Microsoft would be giving up the product.
Most organisations are not in these categories, which is why SharePoint Embedded has gained traction so quickly.
The Licensing and Consumption Model
SharePoint Embedded is sold on a consumption basis, billed through your Azure subscription. The three primary metered dimensions are storage, transactions (Microsoft Graph operations against your containers), and egress bandwidth. There is no per-user licence, no partner programme entry fee, and no requirement for the consuming customer to hold any Microsoft 365 SKU — although certain advanced features (notably Copilot interactions inside SharePoint Embedded documents) do require the consuming user to have appropriate Microsoft 365 licences.
For most ISVs, this consumption model maps neatly to a per-customer or per-workspace cost dimension that can be passed through transparently or absorbed into a subscription tier. In practice, the storage and transaction dimensions dominate — egress is rarely the limiting factor — and the unit costs scale comfortably alongside SaaS gross margins.
The full pricing surface evolves; consult Microsoft’s current documentation for live rates. The point for this article is that SharePoint Embedded’s commercial model is recognisable, predictable, and aligns the cost to the consumption — which is what software vendors generally want.
What Implementation Looks Like at a High Level
A working SharePoint Embedded application has four moving parts:
-
An Entra ID application registration. This is the identity under which your software interacts with SharePoint Embedded. The registration declares the Microsoft Graph permissions you need (delegated for user-level interaction, application for backend operations) and is consented to by each consuming customer’s Entra ID administrator.
-
A registered container type. Created once per ISV, the container type is the descriptor that links your application registration to a class of containers. It declares the permissions model (which permissions on a container correspond to which actions) and is consumed by each customer tenant through a one-time authorisation flow.
-
A Graph integration in your application. Code that creates containers, lists files, manages permissions, and launches Office editing through Graph. Microsoft provides SDKs for the major languages and a comprehensive REST surface for everything else.
-
A consuming-tenant onboarding flow. A first-run experience in which an administrator of the customer organisation grants your application permission to create containers in their tenant context. This is a one-time consent that maps to the container type registration.
We will cover this implementation in step-by-step technical detail in a later Q2 2026 article. For organisations evaluating SharePoint Embedded for the first time, the headline is that the surface area is bounded — there are not dozens of services to learn — and the bulk of the engineering work is integrating Graph, which most ISVs working in the Microsoft ecosystem already do.
How SharePoint Embedded Sits Alongside Office Add-Ins and AI
Three of McKenna Consultants’ four practice areas converge on SharePoint Embedded.
Office Add-Ins. A SharePoint Embedded application that integrates Office for the web is an obvious place to surface custom add-ins. The same Office.js APIs that power task panes in Outlook, Word, Excel, and PowerPoint are available inside the embedded editor, which means you can ship a tailored editing experience for documents stored in your containers. This is a natural pairing for any application that wants to extend the core Office editing surface with its own logic.
AI and Copilot. Documents stored in SharePoint Embedded containers are first-class citizens for Microsoft 365 Copilot. The same grounding and indexing that Copilot uses across SharePoint and OneDrive applies to your container data — so an application built on SharePoint Embedded can offer Copilot capabilities to its users without operating its own retrieval pipeline. For ISVs whose product strategy includes embedding Copilot or building custom Copilot agents, SharePoint Embedded materially shortens the path.
Composable Commerce. Less obvious, but increasingly common: B2B commerce platforms that need attached document workflows — quotes, contracts, specifications, signed agreements — find SharePoint Embedded a clean way to give their buyers and sellers an embedded document experience inside the commerce flow.
This convergence is one reason SharePoint Embedded sits centrally in McKenna’s Q2 2026 content strategy. It touches every other practice area we run.
Where to Go Next
If your organisation is evaluating SharePoint Embedded, the practical next steps are:
- Read Microsoft’s overview at https://learn.microsoft.com/en-us/sharepoint/dev/embedded/overview.
- Review the licensing model and the Microsoft Graph permissions surface.
- Identify a candidate use case in your product where embedded Office editing would be valuable — typically a document workflow that today requires users to leave your application.
- Decide whether SharePoint Embedded or a WOPI-based approach is the better architectural fit. (Our forthcoming decision-framework article will help; the short version is: in most new-build cases, start with SharePoint Embedded.)
McKenna Consultants advises and builds on both SharePoint Embedded and WOPI integrations. We bring two decades of Microsoft document integration experience — initially with SharePoint and Office automation, then deeply with WOPI and the Cloud Storage Partner Program, and now with SharePoint Embedded as the modern path for embedding Microsoft 365 document editing into ISV products. If your organisation is evaluating which path to take, or planning a SharePoint Embedded build, we would be happy to discuss it. Get in touch to start the conversation.
