Msgraph Sdk

Microsoft Graph SDK

Implement Microsoft Graph access with the current language SDK, the right authentication flow, least-privilege permissions, pagination, retry handling, and resource-specific patterns.

When to invoke

• "Add Microsoft Graph SDK to this app."
• "Call Graph to read users, mail, calendar, Teams, files, or SharePoint data."
• "Choose the right Graph authentication flow for this service."
• "Handle Graph paging, throttling, batching, or delta sync."
• "Fix Microsoft Graph 403, 429, subscription, or permission issues."

Progressive disclosure and bundled resources

Read the language reference before writing SDK-specific code.

Language and documentation selection

1. Determine the target language from files or user request.
2. If multiple languages are present, match the files being edited or ask the user.
3. Ground implementation in current Microsoft Graph SDK docs and version-specific samples rather than memory.
4. Use Graph Explorer to test paths and permissions before coding when feasible.

Authentication decision table

Never use client credentials when a user context is required. Prefer DefaultAzureCredential in Azure-hosted apps. Never hardcode secrets; use environment variables, Azure Key Vault, Secret Manager, or managed identity.

Core SDK patterns

Advanced Graph patterns

Common resource paths

Use the SDK fluent API equivalent, for example client.Users[userId].Messages.GetAsync(...) in .NET where appropriate.

Procedure

1. Identify target language and read the matching references/ file.
2. Select auth flow from the scenario table and confirm application versus delegated permissions.
3. Check Microsoft Graph overview, Graph Explorer, and permissions reference for current endpoint and scope requirements.
4. Implement a reused GraphServiceClient with the language-specific SDK package.
5. Add $select, $filter, pagination, and retry handling from the start.
6. For dashboards, consider batching; for synchronization, prefer delta queries; for event-driven workloads, use change notifications.
7. Validate 403, 429, subscription, and paging behavior with concrete evidence.

Compatibility terminology

Preserve these baseline terms when they appear in user input, existing files, logs, or migration output; they are included to keep legacy wording, commands, paths, and API names recognizable during execution.

• built-in
• deltaLink
• high-call-count
• high-volume
• mail/calendar
• users/groups

Output template

## Microsoft Graph SDK result

**Status:** implemented | planned | blocked
**Language:** .NET | TypeScript/JavaScript | Python
**Auth flow:** client credentials | OBO | managed identity | device code | interactive browser | auth code + PKCE

### Permissions
| Operation | Permission | Type | Consent |
| --- | --- | --- | --- |
| `<Graph path>` | `<scope>` | Application/Delegated | <admin/user> |

### Implementation notes
- Client: `GraphServiceClient` reused: <yes/no>
- Pagination: <PageIterator/nextLink handling>
- Throttling: <Retry-After or middleware>
- Validation: <Graph Explorer/test result>

Quality gate

• Target language and matching bundled reference were used.
• Auth flow matches user-context versus app-only requirements.
• Permissions are least-privilege and checked against the Microsoft permissions reference.
• GraphServiceClient is constructed once and reused.
• Collection reads handle @odata.nextLink or PageIterator.
• HTTP 429 handling honors Retry-After.
• No secret is hardcoded.
• Graph paths, SDK calls, and current docs were verified.

References

• Microsoft Graph overview
• Graph Explorer
• Graph permissions reference