How to List Power BI Subscriptions with Admin API

The sales team has relied on the same Monday summary for months. Now its owner is moving to another role. One manager wants the email to continue, another has changed departments, and a third asks whether her region could receive its own Excel file instead.

Before anyone switches a subscription off, you need a trustworthy picture of what is configured. To list native Power BI subscriptions, use the Admin API endpoint for a report, a dashboard or a user. Each answers a different question; none of those three calls is a single tenant-wide subscription inventory.

Start with the reports involved in the handover. Record the subscriptions you find, then speak to the people who depend on them. An enabled subscription tells you that a delivery is configured. It does not tell you whether its contents still help the reader or whether the last email arrived.

Where PBRS helps

The regional manager’s request is more than an inventory question. She needs the right figures in a useful file, delivered consistently. PBRS can manage that work through scheduled exports, recipient-specific distribution and configured destinations, with supported options for combining and protecting the finished files.

Keep the distinction clear: Microsoft’s Admin APIs inventory native Power BI Service subscriptions. PBRS manages its own reporting schedules. It does not discover and automatically take over native subscriptions through these calls. If you decide to move a delivery to PBRS, configure and test that new job as a deliberate change.

That gives the handover a useful purpose. You are finding the emails people still need and deciding how those deliveries should work next—not simply collecting a spreadsheet of identifiers.

Choose the starting point that matches the question. If you are reviewing the sales report, collect that report’s subscriptions. If you are checking a departing colleague’s subscriptions, begin with the user view. For a wider audit, first establish which reports, dashboards or users belong in scope.

The user call accepts a Microsoft Graph user ID or a user principal name. Continue through its returned pages before calling the review complete. A first page is only the beginning when more results are available.

Use an authorized collector

For delegated access, Microsoft requires a Fabric administrator with Tenant.Read.All or Tenant.ReadWrite.All. A token containing a scope is not enough if the caller lacks the required administrator role.

An application using a service principal follows Microsoft’s separate read-only admin API setup. Its approved security group must be covered by the tenant setting, and the app must not have the prohibited admin-consent Power BI permissions configured in Entra ID. Have the administrator check the actual application setup rather than treating delegated and application access as interchangeable.

For someone simply checking their own report email, the service’s subscription interface may be sufficient. The admin inventory is useful when the responsibility extends across reports or people.

Imagine that two of the three report requests succeed and the third is refused. You have useful evidence for two reports, but the third remains an open task. Record that failure separately from a successful request that returns no subscriptions.

Add the decisions the API cannot make

Keep the source, report or dashboard identity, subscription ID, title, enabled state and frequency. Add available content and attachment settings, then confirm the business owner and intended recipients with the team. Do not label a subscriber as the owner merely because their address appears in a response.

Microsoft warns that the users field is being removed; the user-subscription response can already leave it empty or null. Missing subscriber details are therefore not evidence that nobody receives a subscription. Mark what needs confirmation instead of filling the gap with an assumption.

For the Monday summary, the decision might be straightforward: keep the existing native email, confirm who will maintain it and verify the next delivery. A native subscription that already meets the need does not need replacing just because you are auditing it.

Use PBRS when the handover exposes a bigger delivery need

The regional workbook is a different requirement. With PBRS, the team can configure the report, filtering or parameters, output and destination in a recurring job. Data-driven distribution can use recipient information to determine who receives which version, avoiding a separate manual export for each region.

The finished file can also do more for its reader. Supported Excel exports can use formatting, totals and templates; related outputs can be merged into one workbook. Supported PDF outputs can be combined and protected. Choose the capabilities available for the source and format, then test them with the actual report.

PBRS can export from Power BI Service, Power BI Report Server and SSRS. That makes it useful when the handover includes recurring report files from more than one platform. It does not export directly from Power BI Desktop, and a Microsoft Service subscription inventory does not cover every server-side reporting job.

Make the change without losing the Monday email

Agree on the new delivery’s owner, readers, reporting date and expected contents. Run the PBRS job to a test destination and inspect the output. Once the replacement has been accepted, coordinate the cutover so the old and new jobs do not send confusing duplicates—or leave a gap.

Keep the PBRS schedule in a separate inventory, clearly labeled alongside the native records. You can review both in one handover document without pretending they share identifiers, permissions or management APIs.

If your team uses PBRS, include its schedules in the handover rather than stopping at the Microsoft inventory. The PBRS API lets an authorized application discover schedules within known folders and retain the identifiers needed for subsequent management.

Start with a folder supplied by your PBRS administrator. The example below reads its schedules and child folders. It does not execute a report or change a delivery.

GET {pbrsBaseUrl}/api/Folder/GetSchedules?id=12
Authorization: bearer {pbrsAccessToken}
Accept: application/json

GET {pbrsBaseUrl}/api/Folder/GetSubFolders?id=12
Authorization: bearer {pbrsAccessToken}
Accept: application/json

For the handover document, label these rows “PBRS” and retain the installation and folder as well as the schedule identity. Keep Microsoft subscription rows labeled separately. Two jobs with the same title may be unrelated, while one business delivery may have both an old native subscription and a replacement PBRS schedule during testing.

When the review leads to a configuration change, use the documented PBRS schedule lifecycle operations for PBRS jobs. Microsoft’s read-only inventory calls do not make those changes.

By the end of the handover, Monday’s sales summary has someone responsible for it, the regional manager knows what workbook to expect, and the unresolved report request has a named follow-up. That is a useful outcome even before every delivery has been improved.

Use Microsoft’s Admin APIs to establish the native subscription inventory. Where the review identifies a need for richer file preparation and distribution, explore Excel delivery with PBRS and the wider Power BI Report Automation workflow.

Use the evaluation guide below to test one real delivery requirement and confirm how your team will own, monitor and maintain it.

Download the PBRS Internal Evaluation Guide