Forum Discussion
Resolver IIIPublish .pbip using Python script
Hello, At present, there is no official Power BI REST API that allows you to directly publish a .pbip (Power BI Project) folder to a Power BI Premium workspace in the same way that a .pbix file can be imported. The Power BI REST APIs were primarily designed around PBIX-based deployments, and Microsoft has not yet provided a direct "publish PBIP" endpoint. Therefore, if your Python process generates or modifies PBIP files, you cannot simply call a REST API to upload those project files directly to the workspace.
For your scenario, where you have one semantic model (fat report) and two thin reports that are created programmatically using Python, the recommended approach is to continue using the PBIP and Git-based development workflow. Since your Dev workspace is already integrated with Azure DevOps through Git integration, you are already aligned with Microsoft's preferred development model. In this approach, Python can generate or update the PBIP artifacts, commit the changes to the repository, and then allow Fabric or Power BI Git integration to synchronize those changes into the workspace.
If you require a fully automated deployment process, Microsoft is increasingly positioning the Fabric APIs and Git-based deployment workflows as the strategic direction. Fabric APIs provide capabilities for deploying and managing workspace items programmatically and are more compatible with project-based development models such as PBIP. Because of this, migrating toward a Fabric-centric deployment strategy would likely be a better long-term investment than attempting to build custom solutions around PBIX publishing.
In summary, your understanding is correct: Python can create and manipulate PBIP files, but it cannot directly publish those PBIP projects to a Power BI Premium workspace using the traditional Power BI REST APIs. The recommended solution is to use Git integration, deployment pipelines, and, where necessary, Fabric APIs to automate the deployment process. Since you already have Azure DevOps and Git integration working successfully, you are already using the approach that Microsoft currently recommends for PBIP-based development and deployment.
You can deploy pbip using Fabric APIs, with premium or just pro, no xmla endpoint required.
A good wrapper for this is fabric-cicd. I have a blog post on how to use it. I've also written about having multiple repos points to the same workspace, or the same repo pointing to multiple workspaces. Using fabric-cicd gives alot more flexibility than git intergration. That being said with git intergration you have different branches pointing to different workspaces. You can have as many fabric items as you like in a repo (i.e. semantic model, reports).
Hello, At present, there is no official Power BI REST API that allows you to directly publish a .pbip (Power BI Project) folder to a Power BI Premium workspace in the same way that a .pbix file can be imported. The Power BI REST APIs were primarily designed around PBIX-based deployments, and Microsoft has not yet provided a direct "publish PBIP" endpoint. Therefore, if your Python process generates or modifies PBIP files, you cannot simply call a REST API to upload those project files directly to the workspace.
For your scenario, where you have one semantic model (fat report) and two thin reports that are created programmatically using Python, the recommended approach is to continue using the PBIP and Git-based development workflow. Since your Dev workspace is already integrated with Azure DevOps through Git integration, you are already aligned with Microsoft's preferred development model. In this approach, Python can generate or update the PBIP artifacts, commit the changes to the repository, and then allow Fabric or Power BI Git integration to synchronize those changes into the workspace.
If you require a fully automated deployment process, Microsoft is increasingly positioning the Fabric APIs and Git-based deployment workflows as the strategic direction. Fabric APIs provide capabilities for deploying and managing workspace items programmatically and are more compatible with project-based development models such as PBIP. Because of this, migrating toward a Fabric-centric deployment strategy would likely be a better long-term investment than attempting to build custom solutions around PBIX publishing.
In summary, your understanding is correct: Python can create and manipulate PBIP files, but it cannot directly publish those PBIP projects to a Power BI Premium workspace using the traditional Power BI REST APIs. The recommended solution is to use Git integration, deployment pipelines, and, where necessary, Fabric APIs to automate the deployment process. Since you already have Azure DevOps and Git integration working successfully, you are already using the approach that Microsoft currently recommends for PBIP-based development and deployment.
belvoir99AdamMichael thank you so much for such a clear and comprehensive answer!
I won't pursue any further attempts to get pbip automation with Power BI Premium and instead I will begin planning the move to Fabric.
Can I ask just one more question?
I may have this wrong but I believe that, because the workspace (and not the workspace objects) connects to the repo, I can only have one git-integrated report in the workspace. Therefore I would need a workspace for every generated report, fat or thin.
I cannot see anything in the documentation that would enable me to connect multiple reports or semantic models to repo branches within the same workspace.
Indeed, having had a quick read of the CI/CD documentation for Fabric, this seems to be a fundamental principal - one workspace is connected to one repo.
see - https://learn.microsoft.com/en-gb/fabric/cicd/git-integration/intro-to-git-integration and especially see - https://learn.microsoft.com/en-gb/fabric/cicd/git-integration/manage-branches
I am learning so much....!- Deku
Super User
You can deploy pbip using Fabric APIs, with premium or just pro, no xmla endpoint required.
A good wrapper for this is fabric-cicd. I have a blog post on how to use it. I've also written about having multiple repos points to the same workspace, or the same repo pointing to multiple workspaces. Using fabric-cicd gives alot more flexibility than git intergration. That being said with git intergration you have different branches pointing to different workspaces. You can have as many fabric items as you like in a repo (i.e. semantic model, reports).