Premium, PPU, or Fabric capacity: what to enable before automating Power BI

Why Power BI Pro isn't enough

Power BI Pro lets you publish and share reports, but it gives no programmatic access to the semantic model. To create, modify, or read measures through an API — without going through Power BI Desktop — the client's workspace needs to be on a Premium, PPU (Premium Per User), or Fabric capacity. That capacity, and only that, is what exposes the model over the XMLA protocol.

Enabling the XMLA endpoint

Once the workspace is on the right capacity, the XMLA endpoint isn't writable by default. It has to be turned on explicitly, from the Power BI tenant admin side:

• Power BI admin portal → Capacity settings
• Select the relevant capacity
• XMLA Endpoint setting → switch from Off (or Read Only) to Read Write

Without this set to write, an external tool can read the model but never write a measure to it.

Fabric: one more tenant setting

On a Fabric tenant, there's an additional setting in the Fabric admin portal: Service principals can call Fabric public APIs. If it isn't enabled, an application identity (a Service Principal) won't be able to call the API even with the XMLA endpoint correctly set to read/write. It's a tenant-level setting, checked once, independent of any individual workspace.

Granting access without sharing a password

Last step: granting access to the workspace itself. That doesn't require any personal login. You add a dedicated application identity (a Service Principal) as an admin of the workspace, exactly like you'd add a colleague — except it's a technical identity, not a user account, that connects to the model.

Checklist

• Premium, PPU, or Fabric capacity on the workspace (Power BI Pro alone isn't enough)
• XMLA read/write endpoint enabled on that capacity
• On Fabric: tenant setting allowing Service Principals to call public APIs
• The Service Principal added as an admin of the workspace