What causes Executing a large command using the XMLA endpoint?

The TMSL or XMLA command payload exceeds the maximum request size limit enforced by the Power BI XMLA endpoint. Attempting to deploy a large semantic model schema with many tables, measures, or partitions in a single command. Bulk data operations or large SEQUENCE/batch commands being sent as a single request rather than broken into smaller chunks. Using older tooling that does not automatically chunk large payloads before submitting to the XMLA endpoint

How do I fix Executing a large command using the XMLA endpoint?

Step 1: Break the large XMLA or TMSL command into smaller logical units — for example, deploy tables in batches rather than all at once in a single createOrReplace operation.. Step 2: Use Tabular Editor 3 or the latest version of the Analysis Services deployment tools, which handle large schema deployments by chunking requests automatically.. Step 3: If deploying via script, split the TMSL JSON into multiple sequential commands targeting subsets of objects (e.g., individual tables or partition groups) and execute them in order.. Step 4: Capture the RootActivityId from the error response (visible in the Technical Details section) and include it when opening a Microsoft support ticket if the payload size appears to be within expected limits.. Step 5: Upgrade SSMS to version 18.8 or higher to ensure client libraries handle session management correctly when executing commands that approach size limits.

Medium severitycapacity

Power BI Refresh Error:
Executing a large command using the XMLA endpoint

What does this error mean?

Submitting an oversized TMSL or XMLA command payload to the Power BI XMLA endpoint returns a 400 Bad Request error with error code -1052311437. This occurs when the request body exceeds the maximum allowed size for a single XMLA operation.

Common causes

1The TMSL or XMLA command payload exceeds the maximum request size limit enforced by the Power BI XMLA endpoint
2Attempting to deploy a large semantic model schema with many tables, measures, or partitions in a single command
3Bulk data operations or large SEQUENCE/batch commands being sent as a single request rather than broken into smaller chunks
4Using older tooling that does not automatically chunk large payloads before submitting to the XMLA endpoint

How to fix it

1Step 1: Break the large XMLA or TMSL command into smaller logical units — for example, deploy tables in batches rather than all at once in a single createOrReplace operation.
2Step 2: Use Tabular Editor 3 or the latest version of the Analysis Services deployment tools, which handle large schema deployments by chunking requests automatically.
3Step 3: If deploying via script, split the TMSL JSON into multiple sequential commands targeting subsets of objects (e.g., individual tables or partition groups) and execute them in order.
4Step 4: Capture the RootActivityId from the error response (visible in the Technical Details section) and include it when opening a Microsoft support ticket if the payload size appears to be within expected limits.
5Step 5: Upgrade SSMS to version 18.8 or higher to ensure client libraries handle session management correctly when executing commands that approach size limits.

Frequently asked questions

Is there a documented maximum payload size for XMLA endpoint commands in Power BI?

Microsoft does not publicly document a specific byte limit, but the 400 Bad Request with error -1052311437 is the signal that the limit has been breached. In practice, splitting deployments into batches of 10-20 tables at a time reliably avoids this error for most large models.

Can I use Power BI REST API as an alternative to avoid this XMLA size limit?

For refresh operations, yes — the Power BI REST API Enhanced Refresh endpoint supports selective partition refresh and is not subject to the same XMLA payload size constraints. For schema deployments, however, XMLA or TMSL remains the primary path, so batching is the recommended workaround.