The Power BI Export to File API is a REST endpoint that renders a report into a PDF, PowerPoint or image file on request. It is asynchronous: you start a job, poll until it finishes, then download the file. It works well when a developer is building export into an application. It is a heavy lift when the real goal is getting the same reports to the same people every Monday.
This guide covers the call sequence, the formats, the capacity requirements and limits, and the point where a scheduling tool is a better fit than code.
TL;DR
- Export to File is a three-step, asynchronous REST flow: POST an export request, poll the job status, then GET the finished file.
- Standard Power BI reports export to PDF, PPTX and PNG. Paginated reports add formats such as Excel, Word, CSV and XML.
- The report must sit in a workspace on Premium, Embedded or Fabric capacity, and the API enforces per-capacity concurrency limits.
- The API gives you rendering, not scheduling, recipient lists, retries or delivery. You build those yourself.
- If you only need recurring, personalized delivery, a scheduler such as PBRS covers it without custom code.
Table of Contents
- What the Export to File API does
- The three-step flow
- Formats you can export
- Requirements and limits to check first
- What the API does not do
- Build it or buy it: a practical comparison
- Our perspective
- Skipping the code with PBRS
- A decision checklist
- FAQ
- Sources
What the Export to File API does
The endpoint is documented in Microsoft's REST reference as Reports - Export To File. It exports a report to the file format you request, and the call is asynchronous. There is also a variant that targets a specific workspace ("Export To File In Group"), which is the one most production code uses, since reports rarely live in My workspace.

The typical use is what Microsoft calls a send-to-print button: a user clicks, your application triggers a job, and the user receives a file when it completes, as described in the embedded analytics docs. Bookmarks let you export a report in a specific state, including configured filters and slicers.
The three-step flow
Every export, whatever language you write it in, follows the same sequence.
- Send the export request. POST to the report's export endpoint with a body naming the format (for example PDF), and optionally the pages, a bookmark, or filters. The response returns an export ID.
- Poll the status. Call the Get Export To File Status endpoint with that ID until the job reports completion. While it runs, the API returns a number that represents the work completed, based on the number of report pages, per the Microsoft Docs source.
- Get the file. Once the status shows success, call the Get File Of Export To File endpoint and save the stream.
You need an access token for an identity that can read the report, plus the report and workspace IDs. Before any of it works, a Power BI admin has to confirm the tenant settings. According to Microsoft's documentation, exporting to PowerPoint or PDF is enabled by default, while exporting to image files is disabled by default and must be switched on if you want PNG.
A minimal request body
For a standard report, the body can be as small as a format. To export selected pages or a filtered state, you add a report configuration with page names (taken from the Get Pages endpoint) or a bookmark. For paginated reports, the body carries parameter values and format settings instead. Microsoft's example in the paginated documentation exports the first four pages to PPTX by setting a start and end page.
Formats you can export
| Report type | Formats |
|---|---|
| Power BI report | PDF, PPTX, PNG |
| Paginated report | PDF (including accessible PDF), PPTX, XLSX, DOCX, CSV, XML, MHTML, images |
The lists come from Microsoft's documentation for Power BI reports and paginated reports. A multi-page report exported to PNG comes back as a zip with one image per page.
Notice what is missing for a standard report: Excel and CSV. If your finance team wants the data behind a visual in a spreadsheet, the Export to File API will not produce it from a regular report. That is a common surprise, and it is why many teams end up with a second, separate process for spreadsheets. Our own notes on scheduled exports to Excel and the limits of Excel and CSV export in PBRS cover that side.
Requirements and limits to check first
Most failed projects with this API fail on licensing or limits, not syntax. Check these before writing code.
- Capacity. The report must reside in a workspace backed by Premium or Embedded capacity, and Microsoft states the API is not supported for Premium Per User for standard reports. Paginated reports have limited PPU support. Fabric capacity is also listed in the requirements.
- Concurrency. The documented maximum is 500 concurrent requests per capacity. Beyond that you get a 429 Too Many Requests error, and Microsoft's advice is to spread the load over time or across capacities.
- Page processing. Only five pages of a report are processed at once, so a 50-page report is handled in 10 sequential intervals.
- Page cap per export. One exported report can include up to 50 pages or visuals. A request with more is rejected and the job canceled.
- Tenant settings. As noted above, image export needs an admin to enable it.
These figures are from Microsoft's documentation and Microsoft changes them. Read the current Export To File reference and the embedded docs before sizing a design, especially if you plan thousands of exports a day.
What the API does not do
The API renders a file. Everything around it is yours to build:
- Scheduling. There is no built-in timer. You need Azure Functions, a job runner, Power Automate or a cron job to trigger calls.
- Recipient logic. Looking up who gets which report, with which filter, means your own data source and code.
- Delivery. Emailing the file, saving it to a share or pushing it to cloud storage is separate work.
- Retries and alerting. Polling timeouts, 429 responses and expired tokens need handling, and someone needs to be told when a job fails.
- Auditing. If compliance wants a record of what was sent to whom, you log it.
This is not a criticism of the API. It is a building block, and it is designed for developers embedding export in an application. People have wired it into Power Automate too: Chris Webb's series on calling the export API from Power Automate shows how far a flow can go, and how many moving parts it takes.
Build it or buy it: a practical comparison
| Question | Custom code on the API | Report automation software |
|---|---|---|
| Who maintains it? | Your developers | The vendor, plus your admin |
| Scheduling | You build or host it | Built into the product |
| Personalized bursting | Custom loop over recipients | Data-driven schedules |
| Excel and CSV from standard reports | Not available through this endpoint | Depends on the product |
| Delivery destinations | Whatever you code | Configured in the tool |
| Best for | Apps that embed export | Recurring reports to many people |
Building is the right call when export is a feature of your own product, when you need a very unusual workflow, or when you have developers with spare time and a stable requirement. Buying is the right call when the requirement is "send these reports to these people on this schedule, reliably."
We go deeper on the trade-off in Power BI Export to File API vs Report Automation and on the programmatic side in our Power BI report automation API guide.
Our perspective
We have spent more than two decades turning reporting workflows into hands-free processes across Power BI, SSRS, Tableau and Crystal Reports, and the pattern with the Export to File API is consistent. A developer proves the concept in an afternoon. The first PDF arrives, everyone is pleased. Then the requests pile up: a different filter for each region, an Excel copy for finance, a retry when a job fails at 2 a.m., a way to prove to an auditor what went to whom. The afternoon prototype turns into a small product that someone has to own.

Our view is that the API is excellent for what it is meant for, and that scheduled distribution to people is a different problem. It needs flexible schedules, data-driven bursting, event triggers, several formats and several destinations, with error handling that does not depend on one developer's memory. That is the gap PBRS fills for Power BI and SSRS, and it is why we built it to replace manual work and complex scripts rather than to sit beside them.
If you do build on the API, keep jobs small, spread them over time to respect concurrency, and log everything. If you find yourself writing a scheduler, a recipient table and a retry queue, that is the moment to ask whether you are building the right thing.
— Christian Ofori-Boateng
Skipping the code with PBRS
PBRS for Power BI and SSRS is our on-premises report automation software. It schedules Power BI reports, personalizes them for each recipient, exports them to formats such as PDF and Excel, and delivers them to email, cloud, database and collaboration destinations. It supports data-driven schedules and event-triggered workflows, includes a REST API for integration, and handles errors automatically. It is available as a subscription or perpetual license, and the usual path is a free trial or demo first.
If PDF is your main format, start with our walkthrough on how to automate Power BI exports to PDF with PBRS. If you are choosing a schedule pattern, see flexible scheduling of Power BI report exports and the weekly PDF schedule tutorial.
A decision checklist
Answer these five questions and the right path is usually obvious.
- Is export a feature inside your own application? If yes, use the API.
- Do you have Premium, Embedded or Fabric capacity? If not, the standard-report endpoint is off the table, and PPU does not qualify.
- Do recipients need different filters or contents? If yes, count the hours of bursting logic you would have to write.
- Do you need Excel or CSV from standard reports? If yes, plan for something beyond this endpoint.
- Who gets paged when a job fails? If the answer is unclear, you need error handling designed in from the start.
For a broader view of non-API options, our overview of four ways to schedule and export Power BI reports and the complete guide to Power BI export to PDF are good next reads.
FAQ
Is the Power BI Export to File API synchronous?
No. It is asynchronous. A POST starts an export job, you poll the status endpoint until the job completes, and then you download the file. Large reports take longer because the work is measured in pages.
Can I export a Power BI report to Excel or CSV with the API?
Not for a standard Power BI report, which supports PDF, PPTX and PNG. Paginated reports support Excel, CSV and several other formats. For spreadsheet output from regular reports, you need a different approach, such as a scheduling tool.
Does the API work with Premium Per User?
Microsoft's documentation says the API is not supported for Premium Per User for standard reports, and has limited support for paginated reports. Reports generally need to be in a workspace on Premium, Embedded or Fabric capacity. Confirm the current rules in Microsoft's docs before you commit to a design.
What happens when I hit the concurrency limit?
You receive a 429 Too Many Requests error. Microsoft's guidance is to distribute exports over time or across capacities. Queue your jobs and retry with a delay rather than firing everything at once.
Can I export a single page or a filtered view?
Yes. You can name specific pages, and you can use bookmarks to capture a filtered state. Community threads show that exporting individual pages and visuals takes some trial and error, so test with your own reports early.
Sources
- Export Power BI report to file, embedded analytics documentation
- Export Power BI report to file, Microsoft Docs source on GitHub
- Export paginated reports API, embedded analytics documentation
- Calling the Power BI Export API from Power Automate, Part 3
