Join us at FabCon Atlanta from March 16 - 20, 2026, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.
Register now!To celebrate FabCon Vienna, we are offering 50% off select exams. Ends October 3rd. Request your discount now.
I have been wondering for some time the following, until it got me stucked:
If I send API calls like this with an admin user token, it works as intended:
GET https://api.powerbi.com/v1.0/myorg/datasets/{datasetId}/datasources
It also works if I send an API call like this:
GET https://api.powerbi.com/v1.0/myorg/groups/{workspaceId}/datasets/{datasetId}/datasources
However, if I try to use those API calls with a Service Principal, the first one will response me like this:
GET https://api.powerbi.com/v1.0/myorg/datasets/{datasetId}/datasources
Error 403 Forbidden
{
"Message": "API is not accessible for application"
}
But the second one will work as expected.
This behaviour also happens whith other several API calls, and makes me wonder, why? Everything I have found so far points to the easy answer "your Service Principal has not enough API permissions", but right now it has almost every permission possible, but most importantly the ones that are supposed to be needed.
Why is this being a problem? Now, I need to use the following with a service principal, and it won't work
GET https://api.powerbi.com/v1.0/myorg/admin/users/{userId}/artifactAccess
Error 401 Unathorized
{
"error": {
"code": "PowerBINotAuthorizedException",
"pbi.error": {
"code": "PowerBINotAuthorizedException",
"parameters": {},
"details": [],
"exceptionCulprit": 1
}
}
}
But if I try to use the same logic as before, it will response with a 404, since it makes no sense to call an administration API using a workspace.
Why does that happen and how can I solve it?
Solved! Go to Solution.
Hi @SergikitoDZ , The issue arises because Service Principals (SPs) are restricted to workspace-scoped API calls, while admin-level and organization-wide APIs require delegated user authentication. This explains why calling /groups/{workspaceId}/datasets/{datasetId}/datasources works with an SP, but calling /datasets/{datasetId}/datasources directly results in a 403 Forbidden error, as it is an organization-wide endpoint not accessible to applications. Similarly, the admin API (/admin/users/{userId}/artifactAccess) fails with a 401 Unauthorized error because SPs lack delegated permissions, which are required for tenant-wide admin operations. To resolve this, you should use a user account with delegated permissions for admin APIs, while keeping SPs for workspace-level interactions. This is a security limitation set by Microsoft to prevent SPs from performing broad administrative actions across the tenant.
Hi @SergikitoDZ ,
Did the above suggestions help with your scenario? if that is the case, you can consider Kudo or Accept the helpful suggestions to help others who faced similar requirements.
Regards,
Xiaoxin Sheng
Hi @SergikitoDZ , The issue arises because Service Principals (SPs) are restricted to workspace-scoped API calls, while admin-level and organization-wide APIs require delegated user authentication. This explains why calling /groups/{workspaceId}/datasets/{datasetId}/datasources works with an SP, but calling /datasets/{datasetId}/datasources directly results in a 403 Forbidden error, as it is an organization-wide endpoint not accessible to applications. Similarly, the admin API (/admin/users/{userId}/artifactAccess) fails with a 401 Unauthorized error because SPs lack delegated permissions, which are required for tenant-wide admin operations. To resolve this, you should use a user account with delegated permissions for admin APIs, while keeping SPs for workspace-level interactions. This is a security limitation set by Microsoft to prevent SPs from performing broad administrative actions across the tenant.
User | Count |
---|---|
2 | |
2 | |
2 | |
2 | |
1 |
User | Count |
---|---|
10 | |
8 | |
6 | |
5 | |
3 |