Pick the portal family first
Each spec maps to a different portal surface, auth model, and backend. Start with the API page that matches the portal you already use.
Important: treat every POST, PUT, PATCH, and DELETE request as a real tenant write until you have confirmed otherwise. If you only need to understand request shapes, capture browser traffic and start with GET-only validation instead of replaying mutations.
Quick start
These four steps are the safest way to move from portal browsing to reliable API usage.
Prove access with GET requests
Validate cookies, tokens, tenant context, and required headers with read-only endpoints before attempting any state-changing operations.
Use generated artifacts
The site ships both OpenAPI specs and checked-in Postman collections so you can inspect requests before building any automation.
Treat mutations as real writes
Assume POST, PATCH, PUT, and DELETE will change tenant state unless an endpoint is explicitly documented as safe. Use a non-production tenant whenever possible.
Access models
The repo currently spans four distinct ways of authenticating to portal-backed APIs.
Portal session cookies
Defender and Purview rely on the portal's `sccauth` cookie and an authenticated browser session.
Portals: Defender, Purview
Portal session + custom headers
M365 Admin requires `AjaxSessionKey` plus portal routing and hosting headers extracted from the admin shell.
Portals: M365 Admin
Delegated OAuth2
Entra IAM uses the ADIbizaUX resource with delegated user auth only and typically needs `X-Ms-Client-Request-Id`.
Portals: Entra IAM
Azure AD bearer tokens
Entra PIM, IGA, IDGov, and B2C use Azure AD bearer tokens, with tenant- or feature-specific constraints on top.
Portals: Entra PIM, Entra IGA, Entra IDGov, Entra B2C
Portal-family guidance
The notes below separate spec-confirmed details from practical operating guidance for each family.
Defender XDR and Purview
Portals: Defender, Purview
Portal session cookie (`sccauth`)
https://security.microsoft.com/apiproxyhttps://purview.microsoft.com/apiproxyConfirmed in the specs
- Both specs model `PortalSession` as an API key in the `sccauth` cookie.
- Both portals route through `/apiproxy` and call out shared backend prefixes such as `/di/`, `/gws/`, `/medeina/`, `/msgraph/`, and `/shell/`.
- The specs explicitly say these APIs are used internally by the portals and are not officially documented.
Practical guidance
- Authenticate to the portal in a browser first, then capture the active session context before replaying requests elsewhere.
- Expect portal-only behavior such as short-lived sessions, backend-specific authorization, and inconsistent errors across different proxy prefixes.
- Start with list and lookup operations so you can validate the session cookie and shared-service routing without changing state.
Mutation safety
- Treat any POST, PATCH, PUT, or DELETE call as a live tenant change unless you have verified otherwise from portal behavior.
- For mutation mapping, prefer observing browser traffic and saving request/response examples over replaying state-changing calls.
Common pitfalls
- Expired portal sessions usually fail without a helpful auth error.
- Shared prefixes can expose different subsets of the same backend depending on the portal you entered through.
- Because these APIs are internal, some endpoints can disappear or change shape with little warning.
M365 Admin
Portals: M365 Admin
Portal session cookie + custom admin headers
https://admin.cloud.microsoftConfirmed in the specs
- The spec models `AjaxSessionKey` as the session cookie and documents `x-portal-routekey`, `x-adminapp-request`, `x-ms-mac-appid`, and `x-ms-mac-hostingapp` as required headers for most requests.
- The documented application ID is `f00c5fa5-eee4-4f57-88fa-c082d83b3c94`, and the hosting app name is `M365AdminPortal`.
- M365 Admin uses `/admin/api/` and a separate `/fd/msgraph/` proxy instead of the shared Defender/Purview `/apiproxy` layout.
Practical guidance
- Capture the portal bootstrap or initial admin-shell requests so you can reproduce the required routing headers alongside the cookie.
- Keep request context tied to the admin experience you are using; several endpoints depend on admin-shell state in addition to auth.
- Use GET requests against shell, navigation, and current-user endpoints to confirm your headers before touching tenant settings.
Mutation safety
- Assume tenant, user, policy, and app-management endpoints will apply immediately to your tenant.
- When mapping writes, collect payloads from the portal UI and document them before you attempt any replay in a disposable tenant.
Common pitfalls
- Missing one of the custom admin headers can look like a generic auth or routing failure.
- Some data comes through federated Graph proxies and can differ from the shared Graph proxy behavior in Defender or Purview.
- Header values can change as the admin shell bootstraps or refreshes.
Entra IAM
Portals: Entra IAM
Delegated OAuth2 + `X-Ms-Client-Request-Id`
https://main.iam.ad.ext.azure.com/apiConfirmed in the specs
- The spec models OAuth2 authorization code flow against the ADIbizaUX resource `74658136-14ec-4630-ad9b-26e160ff0fc6`.
- The description explicitly says the API only supports delegated auth and does not support service principals or client credentials flow.
- The spec also notes that the majority of requests require `X-Ms-Client-Request-Id` to be set to a GUID.
Practical guidance
- Use Azure Portal or Azure CLI delegated tokens first because the spec documents both as pre-consented clients.
- If you are scripting requests, include a fresh request ID and keep the token scoped to the IAM resource rather than Microsoft Graph.
- Validate permissions with read operations before trying policy or directory writes.
Mutation safety
- Most write endpoints touch core identity objects such as users, groups, apps, and policies, so use an isolated tenant for any experimentation.
- If you only need to understand a write flow, start by capturing the portal request shape and body rather than replaying it immediately.
Common pitfalls
- Using a Graph token or client-credentials flow will not match the auth model documented by the spec.
- Missing `X-Ms-Client-Request-Id` can break otherwise valid requests.
- Portal-only features can expose behavior that does not line up exactly with public Microsoft Graph operations.
Entra PIM, IGA, IDGov, and B2C
Portals: Entra PIM, Entra IGA, Entra IDGov, Entra B2C
Azure AD bearer tokens
https://api.azrbac.mspim.azure.comhttps://elm.iga.azure.comhttps://api.accessreviews.identitygovernance.azure.comhttps://main.b2cadmin.ext.azure.comConfirmed in the specs
- All four specs model HTTP bearer auth with Azure AD JWTs.
- Entra B2C documents `tenantId` query context as required on most endpoints and allows either a GUID or tenant domain.
- The PIM, IGA, and IDGov descriptions all call out license- or feature-gated behavior for some endpoints.
Practical guidance
- Use delegated user tokens with the appropriate Entra role or governance permissions for the portal area you are targeting.
- Keep tenant context, provider IDs, and feature flags in mind when replaying requests because several endpoints are scoped more narrowly than the URL alone suggests.
- Start with list endpoints and configuration reads so you can distinguish missing permission from disabled feature paths.
Mutation safety
- Assume activation requests, access review actions, billing changes, and B2C initialization endpoints are real writes with tenant impact.
- If you are documenting a write flow, capture and annotate the request path, headers, and payload first, then replay only in a safe tenant.
Common pitfalls
- 404 can mean a feature or license is unavailable, not just that the route is wrong.
- B2C and IDGov endpoints often depend on tenant- or provider-specific routing values beyond the bearer token.
- Portal features may fall back to Microsoft Graph for some related workflows, so not every Entra screen maps entirely to these dedicated endpoints.
Safe defaults
These principles apply across every portal surface in the site.
These are undocumented Microsoft portal APIs and may change without notice.
Prefer browser traffic inspection, spec review, and GET-only validation before attempting writes.
Use a non-production tenant for any endpoint that could create, modify, or delete configuration or identity state.
If you need to map POST/PATCH/DELETE behavior safely, observe portal traffic and request bodies without replaying them until you understand the side effects.
Artifacts and entry points
Every published spec page in the site has a matching checked-in Postman collection in the repository.
Defender
261 modeled operations · Portal session cookie (`sccauth`)
Security operations coverage across alerts, incidents, hunting, endpoint, identity, vulnerability, and exposure workflows.
M365 Admin
215 modeled operations · Portal session cookie + custom admin headers
Tenant settings, Copilot controls, reports, user and group management, app settings, and admin shell surfaces.
Purview
74 modeled operations · Portal session cookie (`sccauth`)
Compliance, governance, eDiscovery, audit, insider risk, and shared data-service coverage from the Purview portal.
Entra IAM
277 modeled operations · Delegated OAuth2 + `X-Ms-Client-Request-Id`
Deep IAM coverage spanning users, groups, applications, policies, directories, MFA, and related admin workflows.
Entra PIM
14 modeled operations · Azure AD bearer token
Privileged Identity Management role assignments, requests, permissions, and role-setting workflows.
Entra IGA
14 modeled operations · Azure AD bearer token
Identity Governance administration coverage for entitlement management, guest billing, settings, and lifecycle workflows.
Entra IDGov
11 modeled operations · Azure AD bearer token
Access Reviews and approval workflow coverage including providers, requests, decisions, and feature flags.
Entra B2C
5 modeled operations · Azure AD bearer token + `tenantId` query context
External ID / B2C admin flows, user journeys, tenant information, and initialization-related endpoints.