Getting Started | nodoc

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.

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.

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 12 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 + same-origin XHR

Exchange uses the authenticated Exchange admin center browser session with .AspNetCore.Cookies and same-origin x-requested-with: XMLHttpRequest requests.

Portals: Exchange

Portal session + same-origin context

Purview Portal uses the same sccauth browser session, but its same-origin /api/ calls also depend on portal bootstrap state and are where Purview mints downstream bearer tokens.

Portals: Purview Portal

Portal session + custom headers

M365 Admin requires AjaxSessionKey plus portal routing and hosting headers extracted from the admin shell.

Portals: M365 Admin

Portal session + SharePoint digest

SharePoint uses the tenant's -admin.sharepoint.com browser session together with same-origin SharePoint headers such as x-requestdigest, SdkVersion, and odata-version on POST requests.

Portals: SharePoint

Portal bearer tokens + regional discovery

Teams admin center uses browser-acquired bearer tokens across multiple Teams and Office service hosts, plus same-origin portal context for /api/log and resolver calls that map the tenant to regional backends.

Portals: Teams

MSAL PKCE bearer token + same-origin GraphQL

Viva Engage admin uses a browser-acquired bearer token from the Engage MSAL PKCE flow with the Yammer user_impersonation scope, then calls same-origin persisted GraphQL on engage.cloud.microsoft, a bearer-backed token helper on api.engage.cloud.microsoft, and a transient *.rt.yammer.com Bayeux relay chain whose auth material is carried in the handshake body rather than in Authorization or cookie headers. No cookie header was observed on the authenticated admin API requests captured for this pass.

Portals: Viva Engage

Portal bearer tokens + diagnostic headers

M365 Apps uses browser-obtained bearer tokens together with diagnostic headers such as x-api-name, x-correlationid, x-manageoffice-client-sid, and x-requested-with.

Portals: M365 Apps Config, M365 Apps Services, M365 Apps Inventory

Portal bearer tokens + service-specific audiences

Power Platform reuses browser-obtained bearer tokens from the admin center, but different backends expect different audiences plus portal context headers such as correlation IDs, session IDs, tenant IDs, and app identifiers.

Portals: Power Platform

Portal bearer tokens

Intune Portal and Intune Autopatch use browser-obtained bearer tokens plus same-origin cookies or portal headers from the authenticated Intune session.

Portals: Intune Portal, Intune Autopatch

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 proxy

Portals: Defender, Purview

Portal session cookie (sccauth)

https://security.microsoft.com/apiproxyhttps://purview.microsoft.com/apiproxy

Confirmed 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/.
Defender MTO flows resolve accessible tenants through GET /mtoapi/tenants/TenantPicker, which reflects the operator's current multi-tenant scope.
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.
For Defender multi-tenant flows, capture the paired XSRF-TOKEN/X-XSRF-TOKEN context and mtoproxyurl=MTO routing hint in addition to the sccauth session.
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.
Multi-tenant Defender routes can require extra XSRF and routing context beyond the session cookie alone.
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.

Purview Portal

Portals: Purview Portal

Portal session cookie (sccauth) + same-origin portal context

https://purview.microsoft.com/api/

Confirmed in the specs

Observed operations are same-origin /api/ calls rather than /apiproxy backend routes.
GET /api/Auth/getToken mints short-lived downstream tokens for Purview services, Microsoft Graph, and Azure Resource Manager resources.
Role and feature evaluation happens through GET /api/v2/auth/GetCachedRoles and POST /api/auth/IsInRoles before many blades fully light up.

Practical guidance

Capture requests from an already-authenticated Purview tab because same-origin portal state matters more here than with pure proxy calls.
Expect many useful /api/ calls to be bootstrap or lookup helpers that front other services rather than the final workload APIs themselves.
Start with the read-only auth, role, audit, and picker endpoints so you can validate the session safely before chasing downstream APIs.

Mutation safety

The published same-origin set is mostly read-heavy, but treat any newly discovered POST under /api/ as a live write until you have mapped its side effects.
If Purview uses /api/Auth/getToken to mint a downstream bearer token, validate the target resource with harmless GETs before invoking its write APIs directly.

Common pitfalls

/api/ and /apiproxy/ are distinct surfaces with different responsibilities, so don't assume routing or auth behavior from one applies cleanly to the other.
Some same-origin responses contain user directory or role data, so sanitize captures before keeping artifacts.
Portal-minted downstream tokens are short-lived and resource-specific, which makes replay brittle if you capture them too early.

Security Copilot

Portals: Security Copilot

Portal bearer tokens + workspace context

https://api.securitycopilot.microsoft.comhttps://api.securityplatform.microsoft.comhttps://us.api.securityplatform.microsoft.comhttps://prod.cds.securitycopilot.microsoft.comhttps://securitymarketplaceapi-prod.microsoft.com

Confirmed in the specs

The live portal used a browser-acquired Entra bearer token across api.securitycopilot.microsoft.com, api.securityplatform.microsoft.com, and the regional us.api.securityplatform.microsoft.com content plane.
Security Copilot startup resolved the active workspace through GET /userPreferences/currentWorkspace, then loaded workspace content from regional /pods/{podId}/workspaces/{workspaceName}/securitycopilot/* routes.
Opening the create-capacity dialog triggered POST /provisioning/create and returned OperationWhatIfSuccess before any real submission, which makes it a useful safe write-shape capture point.

Practical guidance

Capture from an already-authenticated portal tab so the current workspace, regional pod host, and browser bearer token all line up with the requests you observe.
Treat the global api.securitycopilot.microsoft.com bootstrap host and the Security Platform content hosts as one portal family; you need both to understand startup and page-specific reads.
Use read-only surfaces such as Agents, Promptbooks, Manage workspaces, Usage monitoring, Build, and Security Store to expand coverage before you attempt any setup or save flows.

Mutation safety

Treat all POST, PUT, PATCH, and DELETE routes as live writes unless you have concrete evidence they are read-like or what-if only.
The captured POST /provisioning/create call appears to be a safe preflight when the dialog is opened and then canceled, but real provisioning and builder save flows still need separate intercepted capture before publication.

Common pitfalls

The portal also touches generic Entra login endpoints, telemetry sinks, and shared Azure Resource Manager reads; keep those out of the published Security Copilot scope unless they become product-specific.
Some builder traffic used malformed empty identifiers such as skillsets//authSettings and sessions//prompts/; those are useful artifact clues but not strong enough for direct publication as stable paths.
Several icon and expiry routes returned contextual 400 or 404 responses in the current workspace, which still confirms the route family but means tenant state matters heavily.

M365 Admin

Portals: M365 Admin

Portal session cookie + route-specific admin headers (plus brokered bearer tokens for some SharePoint-backed helpers)

https://admin.cloud.microsoft

Confirmed 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.
Live captures showed that x-ms-mac-appid is blade-specific rather than globally stable: /homepage, /MicrosoftSearch, /brandcenter, /Settings/enhancedRestore, and /Settings/Services/:/Settings/L1/OfficeOnline all emitted different GUIDs while reusing 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.
Expect SharePoint-backed helpers such as Brand center and Microsoft 365 Backup billing reads to layer additional SPO-specific routing or bearer-token requirements on top of the shell cookies.
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, refreshes, or switches blades; there is no single durable x-ms-mac-appid for the whole portal.

Exchange admin center

Portals: Exchange

Portal session cookie + same-origin x-requested-with

https://admin.exchange.microsoft.com/beta

Confirmed in the specs

Observed Exchange calls were same-origin /beta/ routes on admin.exchange.microsoft.com, not Microsoft Graph.
The published spec models the live Exchange browser session with .AspNetCore.Cookies plus companion chunk cookies and same-origin x-requested-with: XMLHttpRequest requests.
Shared admin.microsoft.com support, SharePoint, and feedback traffic appeared in the same browsing session but was excluded from Exchange coverage because it was generic shell traffic or already documented elsewhere.

Practical guidance

Start from a real signed-in Exchange admin center tab and capture same-origin XHR/fetch requests instead of trying to replay the surface with a guessed token alone.
Treat the OData-style ExchangeAdminCenter.* routes as parameterized functions, not as fixed timestamped paths copied straight out of one capture.
Validate access with read-only bootstrap and list operations such as GET /beta/Shell, GET /beta/UserProfile, GET /beta/AcceptedDomainFullListIC, and GET /beta/MigrationBatch before mapping writes.

Mutation safety

The only write-shaped Exchange route confirmed in this pass was POST /beta/UserPreference; treat additional POST, PUT, PATCH, or DELETE flows as live writes until you have captured and reviewed them carefully.
If you need mailbox, connector, or rule mutations, capture the browser request body and original state first, then replay only in a disposable tenant.

Common pitfalls

Exchange pages also load generic Microsoft 365 shell, support, and feedback traffic from admin.microsoft.com and portal.office.com; do not confuse those hosts with the Exchange beta surface.
A same-origin telemetry POST to /api/instrument/logclient returned 404 during live capture and was intentionally left out of published coverage.
Many useful Exchange routes are OData function calls with embedded parameters, so literal timestamped paths from one capture will be brittle when replayed later.

SharePoint

Portals: SharePoint

Portal session cookie (FedAuth) + same-origin SharePoint headers

https://{tenant}-admin.sharepoint.com/_api

Confirmed in the specs

The observed SharePoint-specific surface is same-origin /_api/* traffic on the tenant's -admin.sharepoint.com host rather than graph.microsoft.com or the generic Microsoft 365 shell.
Observed POST requests included x-requestdigest, SdkVersion, odata-version, and a SharePoint admin Referer alongside the authenticated browser cookies.
The captured routes covered Home, Active sites, Deleted sites, site-detail tabs, Settings, Migration, More features, and Advanced management, with no second SharePoint-specific non-Graph API family beyond /_api.

Practical guidance

Start from a real authenticated SharePoint admin browser tab and keep the tenant-specific -admin.sharepoint.com host intact when replaying requests.
Validate access with read-only calls such as /_api/TenantAdminEndpoints, /_api/TenantInformationCollection, /_api/SPO.Tenant/sites('{siteId}'), or /_api/StorageQuotas() before attempting POST requests.
Expect many useful routes to expose internal SharePoint list names, migration property keys, and service objects rather than polished public contracts.

Mutation safety

Treat POST calls such as RenderAdminListData, ExportToCSV, GetSitesByState, GetSiteAdministrators, and UpdateJobsWorkItems as live portal operations even when they look report-like or read-heavy.
If you need more write coverage, capture the exact portal payload first and preserve original state in a safe tenant before replaying anything.

Common pitfalls

The portal mixes SharePoint-specific /_api traffic with generic shell calls to admin.microsoft.com, portal.office.com, and telemetry endpoints; only the same-origin SharePoint host belongs in this family.
Request digests are short-lived and tied to the current page context, so replay can fail even when the browser cookies are still valid.
Some confirmed routes returned empty or null responses in this tenant, especially migration and settings-adjacent helpers, but they are still real portal endpoints.

Teams admin center

Portals: Teams

Portal bearer token + same-origin portal context

https://admin.teams.microsoft.comhttps://teams.microsoft.com/apihttps://api.interfaces.records.teams.microsoft.comhttps://monitoringplatform.teams.microsoft.com/api

Confirmed in the specs

Most cross-origin Teams admin calls used browser-acquired bearer tokens, while same-origin POST /api/log depended on the active portal context.
The spec preserves separate sections for each discovered API family, including teams.microsoft.com/api, api.interfaces.records.teams.microsoft.com, monitoring, config, virtual visits, monetization, reports, CQD bootstrap, tags, and app catalog services.
Regional discovery is part of normal portal startup via endpoints such as POST /api/authsvc/v1.0/users/region, GET /api/v1/regionalDomainNameForTenant, and GET /api/v1/mta/TenantclusterLookup.

Practical guidance

Start from an authenticated admin.teams.microsoft.com browser tab and validate access with resolver or lookup endpoints before replaying partitioned or regional service calls.
Capture the region, partition, tenant ID, and any region-specific host values first; several Teams backends depend on that discovery chain rather than a fixed global host.
Keep page context in mind when following the portal into reports, app catalog, virtual visits, or telephony flows, because those features fan out to different backend families.

Mutation safety

Treat PUT /api/v1/userpreference and any future Teams POST or PUT outside the confirmed read-like bootstrap calls as live writes with tenant impact.
Even read-like POSTs such as POST /api/authsvc/v1.0/users/region or POST /hasActiveCapabilities should be captured from the portal first so you preserve the exact auth and request shape.

Common pitfalls

The Teams admin center mixes same-origin portal routes, partitioned Teams APIs, and region-specific service hosts, so a valid token alone is not enough if you skip the discovery step.
Some routes, such as virtual visits aggregate records, are real but sensitive to exact query defaults and can return contextual 422 responses when replayed without the right state.
Dashboard widgets introduce adjacent Office-hosted report and app-catalog APIs that are specific to the Teams admin experience even though they do not live on a teams.microsoft.com hostname.

Viva Engage admin

Portals: Viva Engage

MSAL PKCE bearer token + same-origin GraphQL

https://engage.cloud.microsoft/graphqlhttps://api.engage.cloud.microsoft/api/v1/oauth2/aad_access_token

Confirmed in the specs

The first live seed redirected to Microsoft Entra sign-in, which confirmed the MSAL PKCE flow and the https://www.yammer.com/user_impersonation openid profile offline_access scope.
Live capture confirmed same-origin RealtimeConnectionSettingsClients, the cross-host https://api.engage.cloud.microsoft/api/v1/oauth2/aad_access_token helper, and the transient *.rt.yammer.com/cometd/ relay chain that the GraphQL response bootstraps.
Telemetry sinks /api/v1/yamalytics/webui, /api/v2/events, and /api/v3/events were observed in bundles and are intentionally excluded from the published spec.

Practical guidance

Start from an already-authenticated https://engage.cloud.microsoft/main/admin tab and capture the first hydrated GraphQL requests, especially RealtimeConnectionSettingsClients, before chasing bundle-only route hints.
Preserve the MSAL redirect context, requested scope, any Authorization or X-Request-Id headers, and the redacted Bayeux handshake shape, but never store raw token or cookie values in committed artifacts.
The live setup page text frames Generate code and Redeem code as one-time access-code actions used to link an external network, not as a visible billing or purchase flow, but they should still be treated as live writes until the underlying mutation is captured.

Mutation safety

Treat future non-telemetry POSTs under /graphql or api.engage.cloud.microsoft as live writes until the browser flow proves they are read-only.
If you map a new admin mutation, capture the full GraphQL document or request body and confirm the rendered page state before replaying anything.

Common pitfalls

Unauthenticated deep crawls fall back immediately to Microsoft Entra sign-in, so bundle analysis alone is not enough to publish field-level GraphQL operations.
The client bundles still declare legacy Yammer hosts such as msgraph.yammer.com, broadcast.yammer.com, and transient *.rt.yammer.com; only the realtime relay family has direct live-confirmed admin traffic so far.
Conditional X-Yam-* headers appear to depend on request scope and may not be present on every admin request.

M365 Apps admin center

Portals: M365 Apps Config, M365 Apps Services, M365 Apps Inventory

Portal bearer token + diagnostic headers

https://config.office.comhttps://clients.config.office.nethttps://query.inventory.insights.office.net

Confirmed in the specs

All three specs use browser-obtained bearer tokens from the live M365 Apps admin center session.
Observed requests include diagnostic headers such as x-api-name, x-correlationid, x-manageoffice-client-sid, and x-requested-with.
Config covers servicing and policy saves, Services covers feature/onboarding/release lookups, and Inventory covers device, add-in, and security-currency paths.

Practical guidance

Start from a signed-in config.office.com session and validate access with read-only calls on the same host family you intend to automate.
Keep host-specific routing in mind: config.office.com, clients.config.office.net, and query.inventory.insights.office.net serve different parts of the M365 Apps experience.
Use browser capture for write flows first; setup and security-status operations include real POST and PUT requests with tenant impact.

Mutation safety

Treat configuration updates, Setup saves, and Security Currency Goal posts as live writes.
Capture the original values and portal request bodies before replaying any mutation, and test only in a safe tenant.

Common pitfalls

The portal spreads related workflows across multiple hosts that share the same token/header model.
Preview or bundle-only hosts such as canary, sip, or health surfaces are not necessarily active in every tenant.
Missing diagnostic headers can look like generic API or auth failures even when the bearer token is valid.

Intune Portal and Autopatch

Portals: Intune Portal, Intune Autopatch

Portal bearer token + same-origin cookies or portal headers

https://intune.microsoft.com/apihttps://services.autopatch.microsoft.com

Confirmed in the specs

Both specs use browser-obtained bearer tokens from the live Intune admin center session.
Intune Portal also carries same-origin cookies plus portal headers such as x-ms-client-request-id, x-ms-client-session-id, x-ms-extension-flags, and x-requested-with.
Intune Autopatch confirmed live tenant, support, and access-control paths on services.autopatch.microsoft.com, with additional support detail and mutation shapes recovered from the Support requests bundle.

Practical guidance

Start from a real authenticated Intune admin center browser session and validate access with read-only calls such as GET /api/Flighting, GET /api/v1.0/tenant/resolve, or POST /api/Settings/Select.
Keep the current blade in mind when replaying requests: Tenant administration routes can redirect into different blade namespaces such as the roles landing blade or connectors menu.
Expect the portal host to mix useful same-origin APIs with telemetry, ARM calls, and static extension loading; isolate the feature-specific calls before automating.

Mutation safety

Treat POST /api/Settings/Update and any undocumented Autopatch onboarding/support mutations as live writes with tenant impact.
If you need to map a write flow, capture the request shape from the browser first, wait before making a change, record the original value, and revert immediately after testing in a safe tenant.

Common pitfalls

The Intune portal issues a large amount of telemetry and extension bootstrapping traffic that is easy to confuse with real feature APIs.
Some bundles reference Microsoft Graph or public ARM paths alongside the undocumented Intune and Autopatch hosts; only the dedicated non-Graph hosts belong in this family.
Bundle-visible paths are not always safe GETs: PreOnboardTenant returned 405 Method Not Allowed when probed as a GET and should be treated as a likely write-oriented flow.

Power Platform admin center

Portals: Power Platform

Portal bearer tokens + service-specific audiences

https://api.bap.microsoft.comhttps://api.admin.powerplatform.microsoft.comhttps://{region}.adminanalytics.powerplatform.microsoft.comhttps://{region}.csanalytics.powerplatform.microsoft.comhttps://licensing.powerplatform.microsoft.comhttps://{tenantHost}.tenant.api.powerplatform.comhttps://{organizationHost}.crm.dynamics.comhttps://{portalInfraHost}.portal-infra.dynamics.com

Confirmed in the specs

The spec combines nine backend families observed live from admin.powerplatform.microsoft.com, including new *.crm.dynamics.com and *.portal-infra.dynamics.com sections recovered from environment, deployment, security, and Power Pages detail surfaces.
Coverage came from exhaustive same-origin crawling of left-nav routes, list/detail drill-ins, read-only pivots, and safe report interactions rather than a landing-page sweep.
Regional, tenant-scoped, organization-scoped, and portal-infra hosts are modeled with server variables so the same paths cover shard-specific PPAC and Dataverse hosts.

Practical guidance

Start from a real authenticated Power Platform admin center session because the portal fans out across multiple backends with different tokens, headers, and shard-specific hosts.
Drill into list rows, environment hubs, read-only tabs and pivots, and safe report interactions because many dedicated CRM and Power Pages endpoints do not appear on landing views.
Validate access with read-only environment, analytics, capacity, governance, deployment, or portal-management calls on the host family you care about before replaying any mutations.

Mutation safety

Treat Business App Platform POSTs, governance policy operations, and licensing/capacity actions as live tenant changes unless you have proven otherwise in a safe tenant.
When documenting a new flow, capture the original browser request body and headers per host family first because replaying the wrong bearer audience against another backend will fail or produce misleading errors.

Common pitfalls

A token that works for one Power Platform backend is not automatically valid for another backend in the same admin center session.
Regional, tenant-specific, organization-specific, and portal-infra hosts change by tenant and blade, so hardcoding captured hosts will make automation brittle.
Some same-origin routes are tenant-dependent: this crawl hit feature-limited Copilot pages, no-data usage and portal blades, and permission-limited Dataverse user or role-editor details.
The admin center also touches Microsoft Graph, static assets, and downstream Dynamics-related surfaces, so isolate the non-Graph Power Platform hosts before expanding scope.

Entra IAM

Portals: Entra IAM

Delegated OAuth2 + X-Ms-Client-Request-Id

https://main.iam.ad.ext.azure.com/api

Confirmed 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.com

Confirmed 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

Foundational

594 modeled operations · Portal session cookie (sccauth)

Security operations coverage across alerts, incidents, case management, hunting, multi-tenant management, cloud apps, investigation pivots, endpoint, identity, vulnerability, configuration, and exposure workflows.

standardized nav · complete metadata · 457 placeholders · 8 response examples

Open API page OpenAPI source Download collection

M365 Admin

Foundational

280 modeled operations · Portal session cookie + custom admin headers

Tenant settings, Copilot controls, reports, user and group management, app settings, and admin shell surfaces.

standardized nav · complete metadata · 204 placeholders · 9 response examples

Open API page OpenAPI source Download collection

Exchange

Growing

61 modeled operations · Portal session cookie + same-origin x-requested-with

Same-origin Exchange admin center beta coverage for shell bootstrap, preferences, mail flow, recipients, migration, public folders, and report widgets.

standardized nav · complete metadata · no placeholders · 2 response examples

Open API page OpenAPI source Download collection

SharePoint

Growing

41 modeled operations · Portal session cookie (FedAuth) + SharePoint form digest

Tenant bootstrap, site inventory, site-detail blades, storage quota, migration helpers, and settings workflows from the SharePoint admin center same-origin /_api surface.

standardized nav · complete metadata · 1 placeholders · 1 response examples

Open API page OpenAPI source Download collection

Teams

Advanced

99 modeled operations · Portal bearer token + same-origin portal context

Exhaustive Teams admin center coverage spanning left-nav routes, list/detail drill-ins, report interactions, records-backed policy and telephony surfaces, Frontline orchestration, devices, CQD data, app catalog detail pages, monetization, and planning helpers.

standardized nav · complete metadata · 4 placeholders · 4 response examples

Open API page OpenAPI source Download collection

Viva Engage

Advanced

5 modeled operations · MSAL PKCE bearer token + same-origin GraphQL

Authenticated Viva Engage admin coverage now documents the same-origin persisted GraphQL contract, the bearer-backed token helper observed behind engage.cloud.microsoft/main/admin, and the transient Yammer-era realtime relay chain bootstrapped from RealtimeConnectionSettingsClients, together with direct-route captures for segmentation and external-network admin pages.

standardized nav · complete metadata · no placeholders · 4 response examples

Open API page OpenAPI source Download collection

M365 Apps Config

Advanced

23 modeled operations · Portal bearer token + diagnostic headers

Cloud Update, servicing profiles, policy management, device configuration, rollout metadata, and portal bootstrap state from the M365 Apps admin center.

standardized nav · complete metadata · no placeholders · 5 response examples

Open API page OpenAPI source Download collection

M365 Apps Services

Growing

9 modeled operations · Portal bearer token + diagnostic headers

Shared M365 Apps service coverage for onboarding state, feature availability, release catalogs, component sharding, and OneDrive Sync health.

standardized nav · complete metadata · no placeholders · 1 response examples

Open API page OpenAPI source Download collection

M365 Apps Inventory

Growing

27 modeled operations · Portal bearer token + diagnostic headers

Device inventory, build currency, add-ins, setup state, and security update status from the M365 Apps admin center inventory surface.

standardized nav · complete metadata · no placeholders · 1 response examples

Open API page OpenAPI source Download collection

Intune Autopatch

Advanced

53 modeled operations · Portal bearer token + x-ms portal headers

Windows Autopatch tenant state, roles, groups, messages, support, and reporting surfaces from the Intune admin center.

standardized nav · complete metadata · 2 placeholders · 4 response examples

Open API page OpenAPI source Download collection

Intune Portal

Advanced

5 modeled operations · Portal bearer token + same-origin portal context

Same-origin Intune admin center experimentation and persistent portal settings storage used across tenant administration blades.

standardized nav · complete metadata · 1 placeholders · 3 response examples

Open API page OpenAPI source Download collection

Power Platform

Growing

244 modeled operations · Portal bearer tokens + service-specific audiences

Exhaustive admin-center coverage across Business App Platform, analytics, licensing, Dataverse CRM, Power Pages portal infrastructure, tenant governance, notifications, and internal portal helpers used by the Power Platform admin center.

standardized nav · complete metadata · 1 placeholders · 1 response examples

Open API page OpenAPI source Download collection

Purview

Foundational

124 modeled operations · Portal session cookie (sccauth)

Compliance, governance, DLP, insider risk, information protection, and Purview for AI coverage from the Purview portal proxy surface.

standardized nav · complete metadata · 109 placeholders · 4 response examples

Open API page OpenAPI source Download collection

Purview Portal

Growing

8 modeled operations · Portal session cookie (sccauth) + same-origin portal context

Same-origin Purview bootstrap, token minting, role evaluation, audit settings, and label-activity analytics used directly by the portal UX.

standardized nav · complete metadata · no placeholders · 2 response examples

Open API page OpenAPI source Download collection

Security Copilot

Growing

32 modeled operations · Portal bearer tokens + workspace context

Security Copilot portal coverage for bootstrap and preference reads, workspace provisioning and policy resolution, session and promptbook inventory, agent and builder discovery, and Security Store catalog flows.

standardized nav · complete metadata · no placeholders · 1 response examples

Open API page OpenAPI source Download collection

Entra IAM

Foundational

286 modeled operations · Delegated OAuth2 + X-Ms-Client-Request-Id

Deep IAM coverage spanning users, groups, applications, policies, directories, MFA, and related admin workflows.

standardized nav · complete metadata · 73 placeholders · 14 response examples

Open API page OpenAPI source Download collection

Entra PIM

Advanced

16 modeled operations · Azure AD bearer token

Privileged Identity Management role assignments, requests, permissions, and role-setting workflows.

standardized nav · complete metadata · no placeholders · 3 response examples

Open API page OpenAPI source Download collection

Entra IGA

Advanced

11 modeled operations · Azure AD bearer token

Legacy Identity Governance administration coverage for entitlement management, guest billing, connected organizations, and governance settings.

standardized nav · complete metadata · no placeholders · 3 response examples

Open API page OpenAPI source Download collection

Entra IDGov

Advanced

17 modeled operations · Azure AD bearer token

Access Reviews and approval workflow coverage including providers, requests, decisions, and feature flags.

standardized nav · complete metadata · no placeholders · 4 response examples

Open API page OpenAPI source Download collection

Entra B2C

Advanced

6 modeled operations · Azure AD bearer token + tenantId query context

External ID / B2C admin flows, user journeys, tenant information, and initialization-related endpoints.

standardized nav · complete metadata · no placeholders · 3 response examples

Open API page OpenAPI source Download collection