Overview
Microsoft 365 is the productivity platform that the majority of enterprise and mid-market organisations run — email through Exchange Online, calendar and scheduling through Outlook, document collaboration through SharePoint and OneDrive, communication through Teams, and the identity layer through Azure Active Directory. For business applications that need to interact with the communication and scheduling infrastructure that organisations already use, the Microsoft Graph API provides programmatic access to the full breadth of Microsoft 365 data — sending emails, reading calendars, creating calendar events, accessing contacts, managing files in SharePoint and OneDrive, querying user and organisational data from Azure AD.
Outlook and Microsoft 365 integration is relevant across a wide range of business application scenarios. The CRM that sends follow-up emails through the salesperson's Outlook account rather than a generic system address — maintaining the personal sending relationship. The scheduling system that creates calendar events directly in participants' Outlook calendars when appointments are booked. The document management system that stores and retrieves files from SharePoint rather than a separate file storage system. The HR system that reads organisational structure from Azure AD rather than maintaining its own user directory. The business process application that monitors an Outlook shared mailbox for incoming requests and processes them automatically.
The Microsoft Graph API is the unified interface for all Microsoft 365 data access — a single REST API that covers email, calendar, contacts, files, users, groups, and Teams. Authentication is through Azure AD OAuth 2.0, with application permissions for daemon services that operate without user interaction and delegated permissions for applications acting on behalf of specific users. Understanding the permission model — which permissions are required for each Graph API operation, and whether application or delegated permissions are appropriate — is the foundational integration design decision for any Microsoft 365 integration.
We build Microsoft 365 integrations for organisations that need to connect their custom business applications to Outlook email, calendar, SharePoint, OneDrive, and the organisational data that Azure AD holds — covering the programmatic use cases that the Microsoft 365 platform enables for custom software.
What Outlook and Microsoft 365 Integration Covers
Azure AD authentication and permissions. Microsoft Graph API authentication through Azure Active Directory OAuth 2.0.
App registration: the Azure AD application registration in the Azure portal that creates the application identity — the application ID (client ID) and the tenant ID that identify the application. The client secret or certificate used for application authentication. The redirect URI for delegated permission flows where users authenticate interactively.
Application permissions: the OAuth 2.0 client credentials flow for daemon services and background jobs that access Microsoft 365 data without a signed-in user. The application permissions granted to the app registration — Mail.Send for sending email as any user, Mail.Read for reading any user's mailbox, Calendars.ReadWrite for reading and writing any user's calendar, Files.ReadWrite.All for SharePoint and OneDrive file access, User.Read.All for reading all users in the directory. Application permissions require admin consent from a Global Administrator.
Delegated permissions: the OAuth 2.0 authorisation code flow for applications that access Microsoft 365 data on behalf of a specific signed-in user. The delegated permissions that are scoped to the authenticated user's data — Mail.Send for sending email as the signed-in user, Calendars.ReadWrite for the signed-in user's calendar. Delegated permissions require user consent (and sometimes admin consent for high-privilege permissions).
Token acquisition: the POST https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token endpoint for acquiring access tokens. The client credentials flow for application permissions — client ID, client secret, scope (https://graph.microsoft.com/.default), and grant type (client_credentials). The authorisation code flow for delegated permissions — the authorisation URL, the user's consent, the code exchange for access and refresh tokens.
Token caching and refresh: Microsoft Graph access tokens expire after one hour. The token cache that stores the access token and its expiry time, using the cached token until near expiry then requesting a new one. The MSAL (Microsoft Authentication Library) for .NET, Python, and JavaScript that handles token acquisition and caching with built-in refresh logic.
Sending email via Microsoft Graph. Programmatic email sending through a user's Exchange Online mailbox.
Send mail: the POST /v1.0/users/{userId}/sendMail endpoint for sending email as a specific user (application permissions) or POST /v1.0/me/sendMail for the signed-in user (delegated permissions). The message object with subject, body (contentType of Text or HTML and content), toRecipients, ccRecipients, bccRecipients arrays of address objects. The saveToSentItems boolean that controls whether the sent email appears in the user's Sent Items folder.
Attachments: the attachments array in the message object for file attachments. The fileAttachment type with name, contentType, and contentBytes (base64-encoded file content) for attaching files up to 3MB directly in the send request. The upload session approach for attachments larger than 3MB — creating an upload session, uploading the file in chunks, then including the attachment in the message.
Reply and forward: the POST /v1.0/users/{userId}/messages/{messageId}/reply endpoint for replying to a specific email message. The POST /v1.0/users/{userId}/messages/{messageId}/forward endpoint for forwarding a message.
Send on behalf of: the application permission Mail.Send allows sending as any user in the tenant — the integration that sends emails appearing to come from a specific user's email address. The from and sender fields in the message object for specifying the sending identity.
Reading and managing email. Accessing and processing emails in Outlook mailboxes.
Message listing: the GET /v1.0/users/{userId}/mailFolders/{folderId}/messages endpoint for listing messages in a specific folder. The $filter OData parameter for filtering by received date, sender, subject, or other message properties — $filter=receivedDateTime ge 2024-01-01T00:00:00Z. The $select parameter for requesting only the needed message fields to reduce response size. The $top and $skip parameters for pagination, or the @odata.nextLink cursor for efficient pagination through large mailboxes.
Message retrieval: the GET /v1.0/users/{userId}/messages/{messageId} endpoint for retrieving a specific message with its full content. The message body in HTML or text format, the attachment list, the sender and recipient information, and the message metadata.
Folder access: the GET /v1.0/users/{userId}/mailFolders endpoint for listing mailbox folders. The well-known folder names — inbox, sentitems, drafts, deleteditems, junkemail — for accessing standard folders without querying folder IDs. The shared mailbox access that uses the shared mailbox's email address as the userId for application permission access.
Email search: the $search OData parameter for full-text search across message content and metadata — finding emails by keyword, by sender, or by content. The Graph API search that queries Exchange Online's search infrastructure.
Message management: the PATCH /v1.0/users/{userId}/messages/{messageId} endpoint for updating message properties — marking messages as read, moving to a different folder, setting categories. The POST /v1.0/users/{userId}/messages/{messageId}/move endpoint for moving messages between folders.
Delta query for incremental sync: the GET /v1.0/users/{userId}/mailFolders/{folderId}/messages/delta endpoint for incremental email synchronisation — the delta query that returns only the messages that have changed since the last sync, using a delta token to track position. The efficient sync approach that avoids re-processing the full mailbox on each sync cycle.
Mailbox monitoring with change notifications. Real-time notification when new emails arrive or mailbox content changes.
Change notification subscription: the POST /v1.0/subscriptions endpoint for creating a Graph API change notification subscription — the webhook that Microsoft Graph calls when the subscribed resource changes. The subscription with the changeType (created, updated, deleted), the notificationUrl (the webhook endpoint), the resource (the mailbox folder to monitor, e.g., /users/{userId}/mailFolders/inbox/messages), and the expirationDateTime (Graph subscriptions expire and must be renewed — maximum 4230 minutes for mail subscriptions).
Subscription renewal: the PATCH /v1.0/subscriptions/{subscriptionId} endpoint for extending the subscription expiry before it lapses. The renewal job that runs periodically to extend active subscriptions.
Notification processing: the Graph API sends a POST to the notificationUrl when a change occurs. The notification payload with the subscription ID, the change type, and the resource data (the message ID for mail notifications). The notification handler that receives the notification and queries the Graph API for the full message content using the message ID.
Validation token: Graph API subscription creation requires the notification endpoint to respond to a validation request — a GET request with a validationToken query parameter that the endpoint must echo back in the response body. The validation endpoint that responds to subscription validation before the subscription is created.
Calendar access and management. Reading and writing Outlook calendar events.
Calendar listing: the GET /v1.0/users/{userId}/calendars endpoint for listing the user's calendars. The default calendar accessible at GET /v1.0/users/{userId}/calendar.
Event retrieval: the GET /v1.0/users/{userId}/calendar/events endpoint for listing calendar events with date range filtering — $filter=start/dateTime ge '2024-01-01T00:00:00' and end/dateTime le '2024-12-31T23:59:59'. The GET /v1.0/users/{userId}/calendarView endpoint for the calendar view within a specific time window — returning recurring event instances expanded within the window rather than the recurring event definition.
Event creation: the POST /v1.0/users/{userId}/calendar/events endpoint for creating calendar events. The event object with subject, body, start and end (dateTime and timeZone), location, attendees (email addresses and response status), isOnlineMeeting (for Teams meeting creation alongside the calendar event), and recurrence for recurring events.
Meeting invitations: the attendees list in the event creation request — Graph API event creation sends meeting invitations to all listed attendees automatically. The attendees array with each attendee's emailAddress and type (required or optional).
Event updates: the PATCH /v1.0/users/{userId}/events/{eventId} endpoint for updating event properties. The DELETE /v1.0/users/{userId}/events/{eventId} endpoint for deleting events.
Free/busy status: the POST /v1.0/users/{userId}/calendar/getSchedule endpoint for querying the free/busy status of one or more users during a time window — the availability check that scheduling systems use before proposing meeting times.
Contacts access. Reading and managing Outlook contacts.
Contact retrieval: the GET /v1.0/users/{userId}/contacts endpoint for listing contacts. The GET /v1.0/users/{userId}/contacts/{contactId} endpoint for a specific contact. Contact properties including name, email addresses, phone numbers, company, and address.
Contact creation and update: the POST /v1.0/users/{userId}/contacts endpoint for creating contacts. The PATCH endpoint for updating contact properties.
SharePoint and OneDrive file access. Document storage and retrieval through Microsoft's cloud file storage.
OneDrive file access: the GET /v1.0/users/{userId}/drive/root/children endpoint for listing files in the user's OneDrive root. The GET /v1.0/users/{userId}/drive/items/{itemId} endpoint for a specific file or folder. The file download via the @microsoft.graph.downloadUrl property in the item response.
SharePoint site files: the GET /v1.0/sites/{siteId}/drive/root/children endpoint for listing files in a SharePoint document library. The site discovery via GET /v1.0/sites?search={site_name} for finding SharePoint sites by name.
File upload: the PUT /v1.0/users/{userId}/drive/root:/{filename}:/content endpoint for uploading small files (up to 4MB). The upload session API for large files — creating an upload session, uploading file chunks in sequence, completing the upload.
Azure AD user and organisational data. Reading user and organisational information from Azure Active Directory.
User retrieval: the GET /v1.0/users/{userId} endpoint for a specific user's profile — display name, email, job title, department, manager, office location, phone numbers. The GET /v1.0/users endpoint for listing all users in the tenant with filtering and selection.
Organisational hierarchy: the GET /v1.0/users/{userId}/manager endpoint for the user's direct manager. The GET /v1.0/users/{userId}/directReports endpoint for the user's direct reports. The organisational hierarchy that HR and approval workflow systems use for routing decisions.
Group membership: the GET /v1.0/users/{userId}/memberOf endpoint for the groups (security groups, Microsoft 365 groups) the user belongs to — the group membership that access control systems use for permission decisions.
Integration Patterns
Automated email processing. The shared mailbox monitor that watches an Outlook inbox for incoming requests — order confirmations, support requests, invoice submissions — and processes them automatically. The Graph API subscription that delivers notifications when new emails arrive, the message retrieval that reads the email content, the extraction logic that parses structured data from the email, and the routing logic that creates records in the appropriate business system.
Transactional email via user mailbox. The CRM, sales tool, or business application that sends emails through specific users' Outlook mailboxes rather than a generic SMTP relay — preserving the personal sending relationship and ensuring emails appear in the sent folder for the salesperson's reference.
Calendar scheduling integration. The scheduling application that creates Outlook calendar events when appointments are booked — the meeting creation that sends invitations to all participants and blocks the organiser's calendar, without requiring the user to manually create the event in Outlook.
Document management integration. The business application that stores generated documents (contracts, invoices, reports) in SharePoint document libraries rather than a separate file storage system — keeping documents in the organisation's existing file infrastructure.
Directory synchronisation. The application that reads user and organisational data from Azure AD rather than maintaining its own user directory — the HR system, the access management system, or the reporting tool that uses Azure AD as the source of truth for employee data.
Technologies Used
- C# / ASP.NET Core — primary Microsoft 365 integration implementation using the Microsoft Graph SDK for .NET (
Microsoft.GraphNuGet package) and MSAL.NET for authentication - TypeScript / Node.js — Microsoft 365 integration using the
@microsoft/microsoft-graph-clientnpm package and@azure/msal-nodefor authentication - Python — Microsoft 365 integration using the
msgraph-sdk-pythonpackage andmsalfor authentication - Microsoft Graph API — unified REST API for all Microsoft 365 data access
- Azure AD / OAuth 2.0 — authentication and authorisation for Graph API access
- MSAL — Microsoft Authentication Library for token acquisition and caching across .NET, JavaScript, and Python
- Webhooks / Graph Change Notifications — real-time mailbox and calendar change notifications
- REST / HTTP — Graph API communication
- SQL (PostgreSQL / MySQL) — subscription state, email processing records, synchronisation state
- Redis — token caching, subscription renewal tracking, notification deduplication
- Hangfire / scheduled jobs — subscription renewal, incremental email sync, scheduled reporting
- Docker — containerised integration service deployment
- GitHub Actions — CI/CD pipeline for integration service deployment
Microsoft 365 as Business Infrastructure
For organisations standardised on Microsoft 365, the productivity tools — Outlook, SharePoint, Teams, Azure AD — are the infrastructure that business processes run on. Custom applications that integrate with this infrastructure rather than duplicating it serve their users better: the email comes through Outlook, the calendar event appears in the user's own calendar, the document is stored in SharePoint where the existing access controls apply, and the user data comes from Azure AD rather than a separate directory that someone needs to keep current.
The Graph API makes this integration practical with a consistent, well-documented REST interface that covers the full Microsoft 365 surface. The authentication model requires careful setup — the right permissions, the right consent flows — but once established, it provides reliable, long-running access to Microsoft 365 data for the integrations that business applications require.
Microsoft 365 Data, Connected to Your Business Applications
Microsoft 365 integrations built to production standards — correct Azure AD app registration with minimum necessary permissions, MSAL-based token management with automatic refresh, OData query optimisation for efficient data retrieval, Graph change notification subscriptions with renewal management for real-time email and calendar monitoring, and the operational reliability that business-critical integrations require.