How to use Microsoft 365 Copilot Chat API inside Enterprise

Question

According to Microsoft’s documentation, using the Copilot extensibility APIs requires delegated permissions. In a typical SPFx solution, these permissions are declared under webApiPermissions and approved by the tenant admin. This works fine in smaller setups.

However, in an enterprise/organization context, tenant-wide approval is often restricted because it grants privileges across the entire tenant. To avoid this, organizations recommend using individual App Registrations in Azure AD.

Can you help me to give piece of code that authenticate and consume the api using Client ID and Client Secret.

Appreciate your quick response.

Answer 1

Hello Dibakar Pradhan,
You’re right—SPFx webApiPermissions (delegated) become hard to justify in enterprise setups due to tenant-wide consent. In such cases, Client Credentials flow (app-only) using an Azure AD App Registration (Client ID + Secret) is the recommended approach.
Use Client Credentials flow (app-only auth) with an Azure AD App Registration to avoid tenant-wide delegated permissions in SPFx. Instead of webApiPermissions, create an app with Client ID + Secret, grant application permissions, and use MSAL to acquire a token (.default scope). This token can then securely call APIs (e.g., Microsoft Graph) from a backend service, making it ideal for enterprise scenarios where centralized control and least-privilege access are required.

---

Your feedback is important to us. Please rate us: 🤩 Excellent 🙂 Good 😐 Average 🙁 Needs Improvement 😠 Poor

Answer 2

The Microsoft 365 Copilot Chat API is designed to be called with delegated user context and requires a Microsoft 365 Copilot license for that user. The available documentation in context only describes delegated, user-based usage and does not provide a client credentials (client ID + client secret) flow or app-only pattern for the Chat API.

The Copilot APIs are positioned as AI capabilities that “work directly with your Microsoft 365 data” and respect the Microsoft 365 permissions model, where “individuals can only get results from the content they're allowed to access.” This is implemented via enterprise search grounding and user-specific access, which aligns with delegated permissions rather than app-only access.

Because of this, there is no supported pattern in the provided documentation for authenticating to the Microsoft 365 Copilot Chat API using only client ID and client secret (app-only) and then calling it without a delegated user.

For enterprise scenarios, the documented options are:

1. Use the Copilot APIs (including Chat) with delegated permissions and licensed users, so that:
   • The API runs within the Microsoft 365 trust boundary.
   • Enterprise search grounding and web search grounding respect user permissions.
2. Use other Copilot APIs where appropriate (for example, Copilot Retrieval API, Copilot Search API, or Interaction Export API) in architectures that combine Copilot with custom orchestrators or agents, still grounded in user or governed access as described.

The context does not contain any code samples or guidance for:

• Acquiring tokens for the Copilot Chat API using client credentials (client ID + client secret) only.
• Calling the Chat API in an app-only context.

Therefore, a code example for client ID + client secret authentication to the Copilot Chat API cannot be provided based on the available documentation.

---

References:

• Overview of the Microsoft 365 Copilot Chat API (preview)
• Microsoft 365 Copilot APIs overview
• Microsoft 365 Copilot extensibility overview
• Minimum requirements for Microsoft 365 Copilot Chat
• Enterprise data protection in Microsoft 365 Copilot and Microsoft 365 Copilot Chat