Using Graph endpoints instead of bot framework with Teams SDK?

Question

Hi,

I need to know if using graph API endpoints to send conversation messages to specific users/channels for a simple teams app that acts as a bot that sends notifications upon the events received from a different platform is a better way when compared to choosing Teams SDK with bot framework?

Has anyone tried this apart from using Teams SDK which is documented in the official documentation as the primary approach for building teams notification bot apps. Are there any limitations that come along with using the APIs instead of the SDK?

The primary use case should include the bot app to also have a tab as a dashboard along with the user authentication for both Microsoft and other platform.

Answer 1

Hi @Tharushi De Silva

Based on the official Microsoft documentation and practical development experience, it is highly recommended to stick with the Teams SDK / Bot Framework rather than relying purely on Microsoft Graph APIs, especially since your app requires a dashboard tab, dual authentication, and bot-like identity.

While Graph API plays a crucial supplementary role (like proactive app installation), the Bot Framework is the primary, supported path for notification bots. Here is a breakdown of why, and a comparison of the two approaches:

-While you can send messages via Graph, it is generally not designed to replace a standalone bot for several reasons:

+Graph APIs usually require Delegated permissions to send chat/channel messages, meaning the message will appear as if it was sent by the authenticated user (or a generic service account), not a dedicated "Bot" identity. Application permissions for posting standard messages are heavily restricted or unsupported (mostly reserved for migration APIs).

+Because Graph is an HTTP-level REST API, you are responsible for building the entire infrastructure to manage authentication tokens, conversation IDs, retry logic, and state.

+Graph API is subject to stricter throttling limits (e.g., roughly 1 message per second per channel/chat per app/user).

+You can achieve this via Graph (e.g., using TeamsAppInstallation.ReadWriteSelfForUser.All and posting directly), but you still run into the identity issues mentioned above.

-Teams SDK / Bot Framework:

+Messages are sent under the bot's actual name and avatar, providing a professional and clear experience for the end user.

+The SDK natively handles authentication, state management, retry logic, rate limits, and targeting (users vs. chats vs. teams).

+It offers first-class support for Adaptive Cards. If you ever want your notifications to be actionable (e.g., adding a button to "Approve" an event directly in the chat), the Bot Framework handles this seamlessly via Task Modules and action routing. Graph-only setups require massive workarounds to handle interactive button clicks.

+This is natively supported. You can save the conversation reference or use Graph just to proactively install the app for the user, and then hand it off to the SDK to send the message. The Teams Toolkit even has a scaffolded template specifically for "Notification-only" bots.

+Because your use case involves a Tab and dual-authentication, the Teams SDK is the clear winner. You can package the Bot, the Tab, and the SSO logic into a single app manifest. You can use the Teams JS SDK alongside the Microsoft Graph Toolkit to handle the Microsoft login, while managing your external platform auth on your dashboard's backend.

At this time, some developers use Graph for very simple outbound messages (like pushing a static Adaptive Card to a specific channel) or if their backend is already heavily reliant on Graph for M365 administrative tasks. Some also use Graph to send Activity Feed Notifications (via the /teamwork/sendActivityNotification endpoint) rather than standard chat messages.

However, almost all official guidance, production apps and Teams Toolkit samples use the Bot Framework for the actual message delivery.

If you choose the Graph API route, your biggest roadblocks will be the inability to post consistently as a "Bot" (due to app-permission restrictions), the massive overhead of managing tokens/conversation IDs yourself, and a major technical debt if you ever decide to make those notifications interactive in the future.

Please refer the following official documents:
Send chatMessage in a channel or a chat

https://github.com/OfficeDev/Microsoft-Teams-Samples

Hope this helps clarify the best path forward for your project! Let me know if you have any questions about the Teams Toolkit setup.

---

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

For a Teams app that behaves like a notification bot and also exposes a tab with authentication, the Teams SDK plus Bot Framework-style bot is the primary and more flexible approach; using Microsoft Graph messaging APIs alone is not a full replacement.

Key points based on the documented patterns:

1. Graph messaging APIs vs. bot conversations
   • Microsoft Graph offers Teams messaging APIs such as:
     • List messages across a user's chats
     • List messages across channels in a team
   • Graph also supports change notifications for chats and channels for near real-time scenarios and large-scale data streaming without hitting throttling limits. See “Real-time APIs” and “Change notifications for channles and chats”.
   • These APIs are primarily for reading messages and reacting to changes, not for implementing the full conversational behavior of a bot (welcome messages, adaptive cards with actions, multi-turn dialogs, etc.).
2. Recommended notification patterns in Teams Teams documentation describes two main notification frameworks for apps:
   • Activity feed notifications via Graph API to the Teams activity feed.
   • Interactive notification bots that send messages (including Adaptive Cards) into personal chats, group chats, or channels.
   For an app that needs to send notifications based on external events and allow users to interact, the guidance is to use a bot:
   • A bot supports multi-threaded conversation and is more flexible than a webhook.
   • Bots can send proactive messages to users or channels triggered by external events.
   • Proactive messaging requires Teams-specific identifiers, which can be obtained via roster/user profile, conversation events, or Microsoft Graph, but the actual message send is done by the bot.
3. Why a bot (via Teams SDK/Bot Framework) is better suited than Graph-only
   • Bots are the documented way to:
     • Send proactive messages to users/channels.
     • Use Adaptive Cards and rich interactions.
     • Handle conversationUpdate events, cache conversation IDs, and update messages.
   • The Teams SDK abstracts authentication, routing, and event handling, and integrates with Microsoft Graph when needed. It is explicitly positioned to handle the complexity of:
     • Calling Teams backends.
     • Calling Microsoft Graph with app or user tokens.
     • Doing OAuth/SSO flows on behalf of the user.
   • For proactive messaging at scale, documentation shows using Graph to proactively install the app for users, then using the bot (with cached conversation IDs) to send messages.
   Using Graph messaging APIs alone would miss:
   • Bot-specific features (welcome messages, conversation events, adaptive card actions, etc.).
   • The SDK’s built-in auth and event plumbing.
   • The recommended proactive messaging pattern (bot + Graph for installation/IDs).
4. Limitations of a Graph-only approach for this scenario From the documented guidance, limitations of relying only on Graph messaging endpoints for a “bot-like” app include:
   • No first-class bot conversation model (no bot identity in chat, no conversationUpdate events, no Bot Framework activity model).
   • More manual work for authentication, routing, and mapping external events to Teams conversations.
   • Missing the SDK’s support for user-scoped Graph calls (userGraph) and app-scoped calls (app.graph) that are important for combining notifications with a tab and user auth.
5. Combining bot + tab + authentication (your use case) The described use case maps directly to the recommended stack:
   • Bot (via Teams SDK/Bot Framework) for:
     • Proactive notifications to users/channels when external events occur.
     • Rich, interactive messages (Adaptive Cards) if needed.
   • Tab as a dashboard:
     • Teams apps commonly use a tab or personal app as the main UI surface.
     • Documentation explicitly notes that if an app already has a tab/personal app, it is not recommended to build a bot only for notifications; instead, combine them in one app.
   • Authentication:
     • Teams SDK provides patterns for user authentication and calling Microsoft Graph with user tokens.
     • The same app can also integrate auth for the external platform.
6. Where Graph fits in this design Graph is still important, but as a complement, not a replacement:
   • Use Graph to:
     • Proactively install the app for users.
     • Get Teams/roster/user context and IDs needed for proactive messaging.
     • Call other Microsoft 365 APIs (e.g., if the dashboard needs data from Graph).
   • Use the bot (via Teams SDK) to actually send the proactive messages once conversation IDs are known.

Summary:

• For a notification bot + tab + authentication scenario, the documented and more capable approach is Teams SDK + bot with Graph as a supporting API.
• Graph messaging APIs alone are not positioned as a full replacement for bot conversations and would come with functional and integration limitations compared to the SDK-based bot pattern.

---

References:

• Working with Microsoft Teams messaging APIs in Microsoft Graph
• Plan to send app notifications
• Considerations for Teams integration
• Proactive messages
• Graph API Client (typescript)
• Why An SDK?