Issue with Accessing Power BI Admin APIs Using Service Principal (401 Error tryout mode)

[Venkatesh_]

I’m currently facing an issue when trying to fetch data using Power BI REST APIs, particularly the admin endpoints.

It seems like I might not have sufficient admin-level access, although I am an admin for all the relevant workspaces. Surprisingly, when I call the Get (Workspaces) API, it only returns a few test/demo workspaces and does not include the development or production workspaces I’m expecting.

I’m using a service principal to generate the bearer token, and the authentication itself works perfectly fine. But the API returns 401 in tryout mode always.

I want help in working the below API endpoints to build the report.

---

APIs in Question:

• https://api.powerbi.com/v1.0/myorg/admin/...
• https://api.powerbi.com/v1.0/myorg/groups

---

Observations:

• Only limited workspaces (test/demo) are returned
• Expected workspaces (Dev/Prod) are missing
• Admin APIs are not working as expected

---

Question:

Could this be due to tenant-level restrictions, missing permissions, or service principal configuration?

If anyone has faced a similar issue or can point out what might be missing, it would be really helpful.

---

Thanks in advance!

[Venkatesh_]

@parry2k  @v-tejrama 

Thanks for your response. I was able to resolve the previous issue by assigning my application the Fabric Administrator role in Azure, which allowed me to successfully query the admin endpoints.

However, I’m now facing a different challenge. We use Power BI Embedded within our web application, but I can only see activity logs from the Power BI Service—not from the embedded usage.

Since our clients interact exclusively through the embedded reports (and not directly via the Power BI Service), the current activity logs are not useful for tracking actual end-user behavior. My main requirement is to capture and analyze embedded activity—specifically, client-level usage and interactions.

Do you have any insights on why embedded activity is not appearing in the logs, or how we can capture detailed usage for embedded scenarios?

[v-tejrama]

Hi  @Venkatesh_ ,

Thank you for the update. What you are seeing is generally expected in Power BI Embedded scenarios. The Activity Log is primarily intended for auditing activities within the Power BI service and does not provide detailed tracking of end user interactions that occur inside embedded reports. If you are using an App Owns Data model, many actions are performed through the application identity, so embedded user activity is not surfaced as individual user events in the audit logs.
For detailed client level usage analysis, such as report views, page navigation, filter changes, or visual interactions, the recommended approach is to capture telemetry within your application using the Power BI Embedded APIs and store those events in your own monitoring or analytics solution. This provides much more granular insight into how your clients are interacting with embedded content than the Activity Log can offer.

Could you confirm whether you are using an App Owns Data or User Owns Data embedding model and which specific user activities you are looking to track?
That will help determine the most appropriate solution for your scenario.

Thank you.

[Venkatesh_]

@v-tejrama

We are using the App Owns Data approach for Power BI Embedded. I noticed that in the activity logs, the UserId column shows GUIDs instead of actual user emails. These GUIDs appear in events like GenerateToken and ViewReport.
I’m assuming these might be related to embedded activity, but I’m not entirely sure.
Could you help clarify:

Why are we seeing GUIDs instead of user email IDs?
Is this expected behavior for App Owns Data scenarios?
Is there any way to map these IDs back to the actual end users (e.g., via token generation or custom logging)?
Or are we missing some configuration that would allow capturing user identity in the logs?

At the moment, it’s difficult to track real client usage since we cannot associate activity with actual users

[v-tejrama]

Hi @Venkatesh_ ,

Yep, this is expected behavior in an App Owns Data scenario. Since the app or service principal is the identity talking to Power BI, the audit and activity logs usually show object IDs or GUID-based identifiers instead of the actual email addresses of the end users viewing the embedded reports.

There isn’t a setting that will automatically replace those GUIDs with your application users in the Power BI Activity Log. Even when end users are authenticated through your app, Power BI audit logs aren’t meant to give full end-user attribution for embedded usage. So the GUIDs you see in events like GenerateToken and ViewReport usually can’t be used on their own to identify the actual client who viewed the report.

If you need client-level usage tracking, the usual approach is to keep that correlation in the application layer. Since your app knows which user is authenticated when an embed token is generated, you can log that user information alongside report access events and use it to build a complete audit trail of report consumption.

If you’re using effective identities for row level security, those identities help determine what data a user can access, but they aren’t automatically surfaced as user email addresses in the Power BI Activity Log. Based on your description, this seems like expected platform behavior rather than a missing setting or configuration issue.

Thank you.

[v-tejrama]

Hi @Venkatesh_ ,

I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.

Thank you.

[Venkatesh_]

@v-tejrama 

Sorry, How do I get this working? Could you please help me with the steps to follow?  - Since your app knows which user is authenticated when an embed token is generated, you can log that user information alongside report access events and use it to build a complete audit trail of report consumption.

[v-tejrama · Accepted solution]

Hi  @Venkatesh_ ,

This behaviour is actually expected in App Owns Data scenario. In this model, Power BI only sees the application or service principal, not your actual end users. Because of that, in Activity Logs you will see GUIDs instead of user email IDs, and there is no setting in Power BI to change this.

To track real user activity, you need to handle it from your application side. Since your app already knows which user is logged in, you can use that information while generating the embed token. For example, when your backend calls the Generate Embed Token API, you can store details like user email, report ID, workspace ID, and timestamp in your database.

After that, on the frontend, you can use Power BI JavaScript SDK events (like report loaded, page changed, etc.) to capture how the user is using the report. These events can be sent back to your backend and stored along with the same user details. This way you can build your own complete usage tracking and audit report.

Also, even if you are using Effective Identity for RLS, that information is used only internally by Power BI for data filtering and will not come in Activity Logs as user email.

So overall, Activity Log is mainly for service-level auditing, not for detailed end-user tracking in embedded scenarios. For your requirement, maintaining logs in your application is the recommended approach.

Docs Reference

You can refer to below official Microsoft documentation:

Embed content in your Power BI embedded analytics application - Power BI | Microsoft Learn
Audit and usage admin settings - Microsoft Fabric | Microsoft Learn
Power BI embedded analytics Client APIs | Microsoft Learn

Thank you.

[v-tejrama]

Hi @Venkatesh_ ,

I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions

Thank you.

[v-tejrama]

Hi @Venkatesh_ ,

Based on your description, this does not seem to be an authentication issue, as the service principal is successfully obtaining a token and accessing the Groups API. The issue likely relates to permissions or configuration differences between standard Power BI APIs and Admin APIs. For Admin endpoints, the service principal must be enabled in the tenant settings and assigned the necessary tenant-level administrative privileges. Simply being an admin of individual workspaces is typically insufficient for Admin API access.

The Groups API returning only test or demo workspaces indicates the service principal may have access limited to those workspaces. Since the Groups endpoint lists workspaces available to the calling identity, please confirm that the service principal or its security group has access to the Dev and Prod workspaces as well.

I recommend reviewing Power BI tenant settings for service principal access, verifying administrative role assignments, and checking workspace permissions for the missing environments. If possible, please share the specific 401 error details and the Admin endpoint being used, as this information can help determine if the issue is related to tenant permissions or a particular API requirement.

Thank you.

[parry2k]

@Venkatesh_ just curious, are you a tenant admin too? Have you tried using non-admin APIs?