Microsoft 365 Admin APIs and Graph API Basics

#### RESTful Endpoints Graph API uses standard HTTP methods (GET, POST, PUT, PATCH, DELETE) and JSON responses. Resources are organized hierarchically: /users/{id}, /users/{id}/messages, /groups/{id}/members, etc. The API supports OData query parameters like $filter, $select, $expand, $top, $skip, and $orderby. For example:

GET https://graph.microsoft.com/v1.0/users?$filter=department eq 'Sales'&$select=displayName,mail

This returns only the display name and email of users in the Sales department.

#### Batch Requests For efficiency, Graph supports batch requests that combine multiple operations into a single HTTP call. A batch request is a POST to $batch with a JSON payload containing individual requests. Each request can depend on previous ones using @odata.id references. This is crucial for applications that need to perform multiple operations, like creating a user and assigning a license in one call.

Example PowerShell script to get a token:

$body = @{
    client_id = "your-client-id"
    client_secret = "your-secret"
    scope = "https://graph.microsoft.com/.default"
    grant_type = "client_credentials"
}
$response = Invoke-RestMethod -Method Post -Uri "https://login.microsoftonline.com/your-tenant-id/oauth2/v2.0/token" -Body $body
$accessToken = $response.access_token

Then use the token in a request:

$headers = @{
    Authorization = "Bearer $accessToken"
}
$users = Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/users" -Headers $headers

{
  "accountEnabled": true,
  "displayName": "John Doe",
  "mailNickname": "johndoe",
  "userPrincipalName": "johndoe@contoso.com",
  "passwordProfile": {
    "forceChangePasswordNextSignIn": true,
    "password": "xWwvJ]6NMw+bwh-d"
  }
}

This process is fundamental for automation scenarios tested on the exam.

In a large enterprise with 50,000 users, the IT team needs to automate user provisioning from an HR system (e.g., Workday) to Microsoft 365. They build a custom .NET application that uses Microsoft Graph API with application permissions (User.ReadWrite.All, Directory.ReadWrite.All). The app runs as a scheduled task every hour, fetching new hires from Workday via an API, then calling Graph to create users in Azure AD and assign licenses (using POST /users and POST /users/{id}/assignLicense). They also use delta queries to sync changes (e.g., department updates) without re-fetching all users. A common issue is throttling: the app sends too many concurrent requests and gets 429 errors. The solution is to implement a batch processing system that sends requests in batches of 20 (the batch limit) and respects Retry-After. They also use the $batch endpoint to combine multiple user creations into a single HTTP call, reducing load. Another scenario: A SaaS application wants to read Teams messages for compliance monitoring. The vendor registers a multi-tenant app and requests admin consent from each customer. They use the beta endpoint for Teams messages (since v1.0 does not support all Teams features). However, the exam warns that beta endpoints are subject to change; the vendor must be prepared for breaking changes. They also implement delta queries to track new messages efficiently. Misconfiguration example: An admin grants User.Read.All delegated permission but the app runs as a background service (no user signed in). The token request fails because delegated permissions require a user context. The admin must switch to application permissions and re-consent. Another common mistake: forgetting to grant admin consent for application permissions; the app gets 403 Forbidden even with the correct token. The exam tests that admin consent is a separate step after adding permissions.