Admin APIs and automation

Why automation, not the portal

An estate of hundreds of workspaces and thousands of items cannot be governed by hand. The admin REST APIs expose the same surface programmatically, so inventory, lineage, permissions and settings can be pulled on a schedule, diffed, and alerted on — which is exactly serv365's own governance leg.

The admin REST surface

• admin/groups — every workspace, its state, capacity and (with expansion) users/roles.
• admin/capacities, admin/datasets, admin/reports, admin/dataflows, admin/apps — org-wide inventories of each item type.
• admin/activityevents — the activity log (the usage/audit concept).
• admin/widelySharedArtifacts/publishedToWeb and .../linksSharedToWholeTenant — the exposure inventories.
• The MicrosoftPowerBIMgmt PowerShell module wraps much of this: Connect-PowerBIServiceAccount, Get-PowerBIWorkspace -Scope Organization, Get-PowerBIActivityEvent, and the catch-all Invoke-PowerBIRestMethod for endpoints without a dedicated cmdlet.

The scanner (metadata) APIs — the deep read

For full lineage and metadata, the asynchronous scanner APIs are the tool:

1. admin/workspaces/getInfo — kick off a scan of a set of workspaces, requesting detail (datasource details, schema, expressions).
2. admin/workspaces/scanStatus — poll until the scan completes.
3. admin/workspaces/scanResult — retrieve the full metadata: tables, columns, measures, relationships, RLS roles, per-item users, sensitivity labels.

This is how a governance tool reconstructs the whole estate's shape — not just 'what exists' but how it's connected and secured.

App-only (service principal) authentication

Unattended automation authenticates as a service principal (app-only), not a person. Two tenant prerequisites, both governance-critical:

• 'Allow service principals to use Power BI/Fabric APIs' (and the read-only admin API variant) must be enabled and scoped to the SP's security group.
• The SP is added where it needs access (or granted admin read APIs) — least privilege still applies.

The irony worth naming: the very setting that enables governance automation is itself a powerful, dangerous toggle (programmatic access to the whole estate), so it must be scoped to a named group and watched.

Failure modes

• SP over-scoped — a service principal with broad admin API access and a long-lived secret is a high-value credential; leaked, it reads the entire estate.
• The enabling setting left org-wide — 'any service principal' rather than a named group.
• Secret sprawl / no rotation — app secrets that never expire or rotate.
• Read APIs treated as harmless — read-only admin access still exposes all metadata, permissions and lineage.
• Throttling the APIs — admin APIs have request limits; naive polling gets throttled (respect scanner async patterns).

What to watch (proofs)

• The service-principal enabling settings: their state and delegation (named group vs org-wide) captured in the nightly tenant-settings scan (governance concept), with alerting on change.
• Which SPs hold API access: Entra app registrations in the enabling security group, cross-referenced with credential/secret expiry (Get-MgApplication / Get-MgServicePrincipal).
• The estate read itself: Connect-PowerBIServiceAccount + Get-PowerBIWorkspace -Scope Organization and the scanner APIs (getInfo/scanStatus/scanResult) as the recurring inventory and lineage pull.
• API-actor activity: Get-PowerBIActivityEvent filtered to service-principal actors — what the automation identities actually did.