Graph API operations, the Power Automate HTTP connector, SharePoint webhooks, external system integration patterns, and the app registration vs managed identity decision — all explained.
Microsoft Graph is the single API that underpins every integration with Microsoft 365. Whether you're connecting SharePoint to Salesforce, building a custom Teams bot, pulling Azure AD user data into a third-party HR system, or creating an automated provisioning workflow — all of these ultimately go through Graph. Understanding what Graph is, how to query it safely, and how to use it without writing traditional code puts IT admins in a position to design and own integrations rather than depending entirely on external developers.
Microsoft Graph is a RESTful API at https://graph.microsoft.com that provides a unified access point for data across all Microsoft 365 services. Before Graph existed (pre-2017), each Microsoft service had its own separate API — the SharePoint REST API, the Exchange EWS API, the Azure AD Graph API — each with different authentication mechanisms and data formats. Graph unified all of these behind a single endpoint with consistent OAuth 2.0 authentication and JSON responses.
Through a single Graph API connection, you can query and modify data across:
Before building any integration, explore the API using Microsoft Graph Explorer — a browser-based tool that lets you make live Graph API calls against your own tenant (or a sample tenant) without writing any code. It's invaluable for understanding what data is returned before building a flow or integration.
| Operation | Graph URL example | What it returns |
|---|---|---|
| List all SharePoint sites | GET /sites?search=* | All sites in the tenant the user can access |
| Get a SharePoint list | GET /sites/{site-id}/lists/{list-id}/items | All items in a SharePoint list with field values |
| Get a user's profile | GET /users/{user-id} | User object with name, email, department, manager, etc. |
| List Teams a user belongs to | GET /me/joinedTeams | All Teams teams for the authenticated user |
| Send a Teams message | POST /teams/{team-id}/channels/{channel-id}/messages | Creates a message in the specified channel |
| Get calendar events | GET /me/events?$filter=start/dateTime ge '2026-05-23T00:00:00' | Calendar events from today onwards |
| Create a SharePoint list item | POST /sites/{site-id}/lists/{list-id}/items | Adds a new item to the list (body contains field values) |
For IT admins who want to call Graph without writing code, the Power Automate "Send an HTTP request to SharePoint" or the HTTP connector with Graph API is the most accessible path. This lets you query any Graph endpoint from a Power Automate flow, using the flow's built-in authentication — no separate app registration required for many scenarios.
The "Send an HTTP request to SharePoint" action in Power Automate uses the SharePoint REST API (a close cousin of Graph) and handles authentication automatically using the current user's credentials or the flow's service account. It's the quickest way to perform operations not covered by standard SharePoint connectors.
The premium HTTP connector lets you call any Graph URL with full OAuth 2.0 authentication. This requires a Power Automate premium licence or Power Automate Per Flow plan, but unlocks access to every Graph endpoint — including Azure AD operations and cross-service queries not available through standard connectors.
Licensing note: The SharePoint HTTP request action is a standard action (no premium licence needed). The generic HTTP connector for arbitrary Graph calls is a premium action and requires Power Automate premium licensing for the flow user or the flow itself.
SharePoint webhooks allow external systems to receive immediate notifications when content changes in a SharePoint list or library — without polling the API repeatedly. When a webhook subscription is registered, SharePoint sends an HTTP POST to your specified endpoint (a webhook receiver) every time a change occurs.
Critical: Webhook subscriptions expire. SharePoint webhook subscriptions have a maximum lifetime of 180 days. Your integration must renew each subscription before it expires or events will stop being delivered. Build automatic renewal logic into any production webhook integration — check expiry dates and renew at the 150-day mark as a safety margin.
Use webhooks when your integration needs near-real-time data (seconds of latency acceptable). Use polling when webhooks are impractical (short-lived integrations, external systems that can't receive HTTP posts, Power Automate flows with scheduled recurrence). For most business integrations, Power Automate's scheduled flows (5-minute minimum interval) are sufficient and far simpler to implement than custom webhook receivers.
When a Salesforce opportunity moves to "Proposal" stage, a Power Automate flow (using the Salesforce connector) automatically creates a SharePoint site for that deal, provisions the site with a document library, creates a deal summary list item, and posts a notification to the relevant Teams channel. The reverse sync — when documents in SharePoint are tagged "Customer Approved" — can update the Salesforce opportunity record. No custom code required; the Salesforce and SharePoint connectors in Power Automate handle the authentication and data mapping.
When a ServiceNow IT ticket is created, a Power Automate flow uses the ServiceNow connector to read the ticket's category and description, then queries the SharePoint knowledge base via the Microsoft Search API (Graph) for relevant articles. Matching articles are posted back to the ServiceNow ticket as suggested resolutions. Agents who resolve tickets can also push the solution back to SharePoint as a new knowledge article — keeping the knowledge base current without manual copy-paste between systems.
For integrations that need enterprise-scale reliability, complex transformation logic, long-running processes, or connectivity to on-premises systems, Azure Logic Apps is the recommended platform over Power Automate. Logic Apps support all Graph API connectors available in Power Automate, plus direct HTTP calls to Graph, advanced retry policies, and Azure Virtual Network integration for on-premises connectivity. Logic Apps are managed by IT/DevOps rather than citizen developers, making them appropriate for mission-critical business integrations.
This is the question every IT admin faces when setting up a Graph API integration for the first time. Both approaches create a service identity (not a real user account) that the integration uses to authenticate to Microsoft 365. The difference is in how credentials are managed.
| App Registration | Managed Identity | |
|---|---|---|
| What it is | An Azure AD application with a client ID and either a client secret or certificate | An Azure AD identity automatically provisioned and managed by Azure for a specific Azure resource (VM, Function App, Logic App, etc.) |
| Credential management | Manual — you create and rotate client secrets or certificates; secrets expire and must be renewed | Automatic — Azure manages the underlying credentials; no secrets to store or rotate |
| Best for | Integrations from non-Azure systems (on-premises, third-party SaaS, local scripts) | Integrations running inside Azure (Azure Functions, Logic Apps, App Service, VMs) |
| Security posture | Good if managed well — but client secrets in code or config files are a common security incident cause | Excellent — no credentials to steal; authentication is handled by the Azure platform automatically |
| Operational overhead | Higher — secret rotation, expiry monitoring, storage in Azure Key Vault recommended | Lower — zero credential management once configured |
| Graph permissions | Application permissions (acts as itself) or delegated permissions (acts on behalf of a user) | Application permissions only (acts as itself); no delegated auth option |
Security guidance: Never store client secrets in source code, configuration files, or environment variables in plain text. Always use Azure Key Vault to store and retrieve secrets. If your integration runs inside Azure infrastructure, use managed identities instead of app registrations wherever possible — it eliminates the secret management risk entirely.
When you create an app registration or configure a managed identity's Graph permissions, you choose between two permission types:
Sites.ReadWrite.All means the app can read and write every SharePoint site in the tenant. These require explicit admin consent and should be scoped as narrowly as possible.Always apply the principle of least privilege. If an integration only needs to read a specific SharePoint list, don't grant Sites.ReadWrite.All — investigate whether Sites.Selected (granting access to specific sites only) meets your needs, which it often does.
429 Too Many Requests responses and implement retry-after header handlingOceanCloud designs and builds M365 integrations using Graph API, Power Automate, Logic Apps, and custom connectors — from Salesforce and ServiceNow to bespoke ERP systems. We handle the architecture, security, and ongoing monitoring.
Discuss Your Integration