Power BI Service API

The Power BI REST API is a set of RESTful HTTP endpoints that allow developers to programmatically manage and interact with Power BI resources in the Power BI Service. As of 2026, it coexists with the broader Microsoft Fabric REST API, which extends management capabilities across the full Fabric platform including Lakehouse, Warehouse, Notebooks, and Pipelines.

What can be managed via the API

Semantic models (formerly called datasets): trigger refresh, update connection strings, manage parameters, list tables and measures, get refresh history.

Reports: clone, export to PDF/PPTX/PNG, generate embed tokens, retrieve metadata.

Dashboards and tiles: create, update, clone, add tiles.

Workspaces: create workspaces, manage membership, assign to capacity, list contents.

Dataflows: trigger refresh, list, retrieve metadata.

Apps: publish and update Power BI apps.

Capacities: assign and unassign workspaces (admin endpoints).

Gateways: manage gateway data sources and credentials.

Common use cases

Automated refresh triggers — rather than relying on fixed scheduled refresh windows, call the refresh API after an upstream pipeline completes. This creates an event-driven pattern: ETL finishes → API call triggers semantic model refresh → report data is current within minutes of the source update.

Programmatic report export — use the Export Report API to render a report page to PDF or PPTX on a schedule and distribute it via email. Exports support filter overrides, so the same report can be rendered with different filter values for different recipients.

Embedding — generate short-lived embed tokens for "embed for your customers" (app-owns-data) or use a user's access token for "embed for your organization" (user-owns-data) scenarios. The token is passed to the powerbi-client JavaScript library to render the report inside a web application.

Workspace provisioning and tenant management — automate the creation of workspaces, assignment of users and groups, and deployment of reports as part of onboarding new teams or clients.

Monitoring and governance — use the Admin API endpoints to enumerate all workspaces, semantic models, and reports across the tenant, track refresh history, identify failures, and audit capacity usage without manually browsing the Power BI Service.

Authentication

All API calls require an OAuth 2.0 access token issued by Microsoft Entra ID (formerly Azure Active Directory). The token must carry appropriate Power BI service scopes such as Dataset.ReadWrite.All or Report.Read.All. For automated and server-side scenarios, service principals using the client credentials grant are the recommended authentication approach.

Fabric REST API

Beginning in 2024, Microsoft introduced Fabric-specific REST endpoints at https://api.fabric.microsoft.com/v1/... for managing Fabric items such as Lakehouses, Warehouses, Notebooks, and Pipelines. Power BI resources in Fabric-enabled workspaces can be managed through either the classic Power BI API or the Fabric API. The Fabric API is the forward-looking surface for new capabilities and cross-platform management, while the Power BI API remains fully supported for existing integrations.

Authentication to the Power BI REST API uses Microsoft Entra ID (formerly Azure Active Directory) OAuth 2.0. There are two primary authentication scenarios depending on whether the caller is a human user or an automated process.

Scenario 1: Delegated authentication (user context)

Used for interactive applications where a signed-in user's identity and permissions drive what data they can access.

1. Register an application in the Microsoft Entra admin center. Note the Application (client) ID and tenant ID.
2. Under API permissions, add Power BI Service delegated permissions appropriate to the intended operations — for example, Dataset.Read.All, Report.ReadWrite.All. Grant admin consent for the tenant if the permissions require it.
3. Configure a redirect URI for the OAuth authorization code flow.
4. When a user signs in, redirect them to the Entra authorization endpoint. The user authenticates with their Microsoft credentials and consents to the requested permissions.
5. Your application receives an authorization code, then exchanges it for an access token by posting to the Entra token endpoint: POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
6. Include the access token in the Authorization: Bearer {token} header on all requests to https://api.powerbi.com/v1.0/myorg/....

The token expires (typically after one hour); use the refresh token to obtain a new access token without requiring the user to re-authenticate.

Scenario 2: Service principal authentication (app context)

Recommended for automation, CI/CD pipelines, and any server-side process where no human user is present.

1. Register an app in the Entra admin center. Create a client secret or, preferably, a certificate (certificates are more secure for production scenarios). Note the client ID.
2. In the Power BI tenant admin settings (powerbi.com/admin), enable "Allow service principals to use Power BI APIs". You can restrict this to a specific Entra security group for tighter control.
3. Add the service principal as a Member or Admin on the relevant Power BI workspace. Service principals cannot be added as workspace admins from the UI in all tenants — this is sometimes done via the API itself.
4. Request a token using the client credentials grant: POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token Body: grant_type=client_credentials client_id={client_id} client_secret={client_secret} scope=https://analysis.windows.net/powerbi/api/.default
5. Use the returned access token in all API calls exactly as in the delegated scenario.

Service principal tokens do not expire with a user session; the client credentials grant issues a new token on each call, making it suitable for long-running or unattended automation.

Microsoft Authentication Library (MSAL)

Both scenarios are simplest to implement using the MSAL SDK, available for .NET, Python, JavaScript, Java, and other languages. MSAL handles token acquisition, caching, and silent refresh automatically, so application code only needs to call acquire_token_for_client() (service principal) or acquire_token_interactive() (delegated) and pass the result to the API.

Fabric REST API

The same Entra ID tokens work for Fabric REST API calls at https://api.fabric.microsoft.com/v1/.... The scope for Fabric API authentication is https://api.fabric.microsoft.com/.default instead of the Power BI-specific scope above.

"Report generation" via the Power BI Service API covers two distinct problems: keeping the underlying data current (refresh) and producing a rendered output file (export). Both are achievable through the REST API and are commonly combined in automated pipelines.

1. Triggering semantic model refresh

Use the refresh endpoint to pull new data into a semantic model on demand, outside any scheduled refresh window:

POST https://api.powerbi.com/v1.0/myorg/datasets/{datasetId}/refreshes
Authorization: Bearer {token}
Content-Type: application/json
Body: { "notifyOption": "MailOnFailure" }

This call is typically made from an orchestration layer — Azure Data Factory, a Fabric Pipeline activity, Azure Logic Apps, or a custom script — immediately after upstream data processing completes. This creates an event-driven refresh pattern: data lands in the source → pipeline triggers the refresh API → the semantic model is updated within minutes, rather than waiting for the next scheduled window.

Monitor refresh completion by polling:

GET https://api.powerbi.com/v1.0/myorg/datasets/{datasetId}/refreshes

Each refresh entry returns a status field: Completed, Failed, or Unknown (in progress). Poll until status is no longer Unknown before proceeding to export.

2. Exporting reports to PDF, PPTX, or PNG

The Export Report API renders a report to a file format asynchronously:

POST https://api.powerbi.com/v1.0/myorg/reports/{reportId}/ExportTo
Body: {
  "format": "PDF",
  "powerBIReportConfiguration": {
    "pages": [{ "pageName": "ReportSection1" }]
  }
}

The response returns an exportId. Poll the status endpoint until the export succeeds:

GET https://api.powerbi.com/v1.0/myorg/reports/{reportId}/exports/{exportId}

When status is Succeeded, the response includes a download URL. Retrieve the file with a GET to that URL.

Parameterized exports with filter overrides

The export request body accepts reportLevelFilters, allowing the same report to be exported with different filter values per recipient. This enables a single automated job to produce personalized PDF outputs — for example, one export per regional sales manager filtered to their territory — without maintaining separate reports.

3. Paginated Report export

Paginated Reports (available in Premium, PPU, or Fabric capacity) use the same ExportTo endpoint with format: "PDF" or "XLSX". The key difference is that paginated reports accept parameter values in the request body, enabling pixel-perfect, multi-page documents driven by dynamic inputs — useful for invoices, statements, or regulatory filings.

4. End-to-end automation pipeline

A typical production pattern:

1. ETL completes — Fabric Pipeline or Azure Data Factory finishes loading fresh data into a Lakehouse or data warehouse.
2. Trigger refresh — a pipeline activity or webhook calls POST /datasets/{datasetId}/refreshes.
3. Poll for completion — check GET /datasets/{datasetId}/refreshes in a loop (with a delay between polls) until the latest refresh shows Completed.
4. Export report — call POST /reports/{reportId}/ExportTo with the desired format and any filter overrides.
5. Poll for export — check GET /reports/{reportId}/exports/{exportId} until Succeeded.
6. Distribute — download the rendered file and send it via Power Automate, Azure Logic Apps, SendGrid, or another email service.

This pattern decouples report delivery from fixed schedules, ensures recipients always receive data that reflects the latest completed ETL run, and requires no manual intervention once configured.

Power BI embedding is built on the Power BI Embedded platform, combining the REST API (for authentication and token generation) with the powerbi-client JavaScript library (available as vanilla JS and as React/Angular wrappers) to render reports inside a web application. There are two distinct embedding scenarios with different authentication models, and choosing the wrong one is a common mistake.

Scenario A: Embed for your organization (user-owns-data)

This scenario is for internal applications where every viewer has their own Microsoft or Power BI account.

1. Register an application in Microsoft Entra ID with delegated Power BI permissions.
2. The user signs in with their own credentials through the MSAL OAuth authorization code flow.
3. Use the user's access token to call GET /reports/{reportId} and retrieve the embedUrl.
4. Pass the embedUrl and the user's access token directly to the powerbi-client library — no separate embed token is needed.
5. The report renders under the user's own identity. Row-level security roles defined in the semantic model apply automatically based on the user's account.

This scenario requires no special capacity licensing for the embedding itself, but every viewer must have a Power BI Pro or PPU license.

Scenario B: Embed for your customers (app-owns-data)

This scenario is for ISVs and external-facing applications where end users do not have Power BI accounts or licenses.

1. Register an app in Entra ID. Create a service principal (preferred) or a master user account.
2. Enable service principal access in the Power BI tenant admin settings and add the service principal to the workspace as a Member or Admin.
3. Authenticate the service principal using the client credentials grant to obtain an access token.
4. Call the GenerateToken API to create a short-lived embed token scoped to the specific report and dataset: POST https://api.powerbi.com/v1.0/myorg/groups/{groupId}/reports/{reportId}/GenerateToken Body: { "accessLevel": "View" } To enforce row-level security for the viewer, include an identities array in the request body with the username and the RLS role name. The embed token bakes the RLS context in — the viewer sees only their data without needing a Power BI account.
5. Retrieve the embedUrl from GET /groups/{groupId}/reports/{reportId}.
6. Initialize the embedded report using the powerbi-client library:

   const config = {
     type: 'report',
     id: reportId,
     embedUrl: embedUrl,
     accessToken: embedToken,
     tokenType: models.TokenType.Embed,
     settings: {
       filterPaneEnabled: false,
       navContentPaneEnabled: false
     }
   };
   const report = powerbi.embed(containerElement, config);

1. Handle token expiry in the application — embed tokens are short-lived (default one hour). Implement a tokenExpired event listener to silently obtain a new embed token and call report.setAccessToken(newToken) without re-rendering the report.

Licensing for Scenario B

Embedding for customers (app-owns-data) requires the workspace to be assigned to a capacity — either a Power BI Embedded A-SKU (Azure, billed per-hour when active) or a Fabric F-SKU. Without a capacity assignment, the GenerateToken API returns an error. P-SKUs also work but are monthly commitments. For development and testing, the A1 SKU can be paused when not in use to reduce cost.

Programmatic interaction after embedding

The powerbi-client library exposes the embedded report as a JavaScript object that supports:

• Applying filters — report.setFilters([...]) to programmatically filter data without showing the filter pane to users
• Changing pages — report.setPage('pageName') to navigate to a specific report page
• Capturing events — listen for pageChanged, dataSelected, rendered, or error events to drive application behavior based on user interaction
• Exporting — report.print() or triggering the Export API from the server side for PDF output

This makes Power BI embedding a first-class component in web applications, not merely an iframe with a static view.

The Power BI REST API (and the broader Microsoft Fabric REST API) supports a wide range of operation categories:

Semantic model (dataset) operations

• List semantic models in a workspace
• Get semantic model details (tables, columns, relationships, data sources)
• Trigger a refresh (POST /datasets/{id}/refreshes)
• Get refresh history and status (monitor for completion or failure)
• Update parameters (e.g., change a database connection string)
• Bind a semantic model to a gateway data source
• Manage row-level security (RLS) roles and members

Report operations

• List, get, clone, and delete reports
• Export a report to PDF, PPTX, or PNG (async export API with polling)
• Clone a report to another workspace
• Rebind a report to a different semantic model
• Get embed URL for embedding in applications
• Update report content (via import of a .pbix file)

Dashboard and tile operations

• Create, update, clone, and delete dashboards
• Add tiles (from reports or custom HTML)
• Get tile embed URLs

Workspace (group) operations

• Create, update, and delete workspaces
• Add and remove workspace members and set their access roles
• Assign a workspace to a Premium or Fabric capacity
• List all workspaces across the tenant (Admin API)

Dataflow operations

• List, get, and trigger refresh of dataflows
• Get and update dataflow transactions
• Export dataflow definitions

App operations

• Publish and update Power BI apps
• Get apps available to the calling user
• Get reports and dashboards within an app

Gateway and data source operations

• List gateways and their data sources
• Add data sources to a gateway
• Update credentials for a data source
• Test gateway connectivity

Capacity operations (Admin)

• List capacities and their workspaces
• Assign or unassign workspaces from capacities
• Get capacity refreshables (items currently refreshing)

Embed token operations

• POST /GenerateToken — generate an embed token for a specific report/dashboard
• POST /EmbedToken/GenerateToken — batch embed token for multiple reports/datasets in one call (more efficient for multi-report embedding scenarios)

Admin / tenant-wide operations

• Get all workspaces across the tenant (with audit information)
• Get all reports, datasets, and dashboards across the tenant
• Get activity events (audit log) for governance and monitoring
• Manage tenant settings programmatically

Fabric-specific operations (Fabric REST API) With Microsoft Fabric's broader REST API (api.fabric.microsoft.com), additional operations are available:

• Manage Lakehouse items (create, delete, list tables)
• Trigger Spark Notebook executions
• Manage Data Factory pipelines (create, trigger, monitor)
• Manage Fabric capacity and SKU assignments
• Git integration: commit/update workspace items to a connected git repository

The Power BI Admin APIs and Fabric APIs together form the basis of enterprise-scale governance automation — used for tenant-wide reporting on content sprawl, capacity utilization tracking, and compliance auditing.

import requests

url = 'https://api.powerbi.com/v1.0/myorg/datasets'
headers = {'Authorization': 'Bearer '}

data = {
    'name': 'Sales Dataset',
    'tables': [
        {
            'name': 'Sales',
            'columns': [
                {'name': 'Date', 'dataType': 'DateTime'},
                {'name': 'Amount', 'dataType': 'Double'},
                {'name': 'Product', 'dataType': 'String'}
            ]
        }
    ]
}

response = requests.post(url, headers=headers, json=data)

if response.status_code == 201:
    print('Dataset created successfully')
else:
    print('Failed to create dataset')

import requests

url = 'https://api.powerbi.com/v1.0/myorg/dashboards'
headers = {'Authorization': 'Bearer '}

data = {
    'displayName': 'Sales Dashboard',
    'defaultTileSize': 'Medium'
}

response = requests.post(url, headers=headers, json=data)

if response.status_code == 201:
    print('Dashboard created successfully')
else:
    print('Failed to create dashboard')