How to Export Power BI Reports to PDF Programmatically

Imagine an operator finishing the month’s billing run. She needs a management-summary PDF in the shared folder before the finance review. A response saying “request accepted” is helpful progress, but she still needs to know when the document is ready.

Build the integration around that outcome. Keep the billing month with the report request, and make it possible to distinguish a report still being generated from a file that failed to reach its destination.

With PBRS, prepare a schedule that produces the summary PDF and delivers it to the folder. Your application can then start that job through the API. When reporting requirements change, the report selection and delivery settings remain in the reporting tool.

With Microsoft’s ExportTo API, the application owns the individual stages: start the export, monitor it, retrieve the PDF and save or send it. That can be a good fit when your application specifically needs that control and your team is prepared to maintain it.

Microsoft’s standard-report ExportTo route requires supported Premium, Embedded or Fabric capacity for the report and related semantic models; PPU is not supported. Its documented limits include 50 page/visual exports per request and a 250 MB output. Check the export guidance for report features and tenant settings that affect eligibility.

Authentication also depends on the approach. Delegated export requires the applicable report and dataset scopes as well as content access. A service principal uses the required tenant setup and workspace access; adding delegated permissions is not an equivalent configuration. Microsoft also restricts service-principal PDF/PPTX exports of sensitivity-labeled reports.

A PBRS integration needs a working PBRS installation, its API service, an authorized source account and access to the destination. The application must still decide which users may request which reports.

Before wiring up the billing button, produce the management summary with the intended reporting month and pages. Ask the report owner which total confirms that the completed billing run is included. This gives you a concrete document to compare with the application’s first result.

For PBRS, configure the report, PDF output and destination in a saved schedule and run it from PBRS first. Confirm that the delivered copy is the one finance expects. Then connect the application to that known job.

If the reporting month changes for each request, make that selection explicit through the supported schedule configuration. An unattended job does not inherit whichever month happens to be selected in someone’s open browser.

Give the application a useful progress message, such as “Preparing the billing summary” followed by “Saved to the finance folder.” Keep errors specific enough for the support team to tell whether to investigate the report or the destination. Store request identifiers without putting access tokens or confidential report contents into ordinary logs.

Run the prepared PBRS job

Use the following pattern for an existing single-report schedule. Replace the example ID and connection values with the authorized billing job.

POST {pbrsBaseUrl}/api/Schedule/ExecuteScheduleAsync
Authorization: bearer {pbrsAccessToken}
Content-Type: application/json

{"ScheduleType":"report","uniqueid":101,"RunBy":"Billing batch"}

GET {pbrsBaseUrl}/api/Schedule/GetExecutionStatus?ExecutionId={ExecutionId}
Authorization: bearer {pbrsAccessToken}

Save the returned ExecutionId with the billing month. The uniqueid identifies the schedule; ExecutionId identifies this particular run. RunBy is a descriptive label, not an authorization control.

Waiting and Executing indicate progress. When the execution is Completed, parse the string-valued ResultJson and inspect Result, ErrorMessage and ErrorNumber: a completed execution record can still report a failure. The execution guide explains the response and monitoring behavior.

Use a polling deadline and check an uncertain execution before starting another. A local timeout does not cancel the PBRS job, so an immediate retry could produce another delivery.

Build a direct Microsoft export

If the application owns the export sequence, the basic HTTP outline is:

POST https://api.powerbi.com/v1.0/myorg/groups/{groupId}/reports/{reportId}/ExportTo
Authorization: Bearer {accessToken}
Content-Type: application/json

{"format":"PDF"}

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

Store the export ID, respect Retry-After when supplied, and retrieve the file after Succeeded and before it expires. Confirm that the response is the PDF, then perform your destination step. These requests are an implementation outline; your backend also needs authentication, error handling and recovery.

For the billing operator, the result is a management summary ready for the finance review. Choose direct Microsoft export when your application needs to own each stage. Choose PBRS when you want the application to request a reporting job whose output and delivery are maintained together.

Explore the PBRS report automation API for that approach, or see Power BI Report Automation for the wider scheduling options.

Download the PBRS Internal Evaluation Guide