How to Trigger and Monitor Power BI Refresh with REST API

The accounts team has closed the month. A customer calls for an updated statement, and the operator sees a reassuring message: “Refresh requested.” Unfortunately, that message does not answer the customer’s question. The statement could still contain the previous month’s balance.

A Power BI refresh request starts an asynchronous operation. A 202 Accepted response confirms that the service accepted it; the application must still follow the matching refresh to find out how it ended. Producing and delivering the statement are further steps.

PBRS is useful when that complete reporting process is the real task. You can configure the required dataset refresh, customer selection, PDF output and destination in PBRS, then let your application request the job when the billing load is ready. The application can track its execution instead of building every export and delivery step itself.

Keep the business event in view

Give the billing run a recognizable reference, such as its batch identifier and close date. Keep that reference with the technical execution records. When a customer asks about a statement, the operator should be able to trace the file back to the billing run that produced it.

A successful refresh can still load older data if it starts before the intended source load finishes. Check a known close date or newly loaded transaction as well as the refresh result. Those checks answer different questions: did the operation work, and did it include the data we were waiting for?

There are two sensible starting points. If the application needs to update a semantic model, Microsoft’s refresh API provides that control. If it needs to send a finished customer document, PBRS can manage the reporting work around the refresh.

For our billing team, PBRS can retain the customer filters, file format, protection and destination alongside the refresh settings. The team can maintain those reporting choices without asking a developer to change the application’s export logic whenever the document requirements change.

Choose which component starts the refresh. If the application already performs it, do not unintentionally configure PBRS to request the same refresh again. If PBRS owns it, configure and test that behavior in the reporting job before adding the application trigger.

Check the model and identity first

Power BI Service calls the object a semantic model, while the REST API still uses datasets in its paths. The workspace identifier is groupId; the model identifier is datasetId. Use the identifiers for the intended environment rather than relying on a report’s display name.

For delegated authentication, the refresh operation requires Dataset.ReadWrite.All. Reading history accepts that scope or Dataset.Read.All, and the caller must have Write permission on the model. A service principal needs its supported tenant and workspace setup; do not treat a delegated-user token recipe as interchangeable.

On shared capacity, native API requests and scheduled refreshes share an eight-refresh daily allowance. Enhanced refresh is not supported there. PBRS does not increase Power BI’s refresh allowance, so plan the workflow around the model’s actual capacity and refresh needs.

Start with a representative billing run and a test destination. Confirm that the model can refresh successfully and that the report shows the expected close date. Then connect the automated steps.

If the application calls Power BI directly

Submit a POST to the workspace and model’s refreshes endpoint. Retain the returned request identifier and operation location, where supplied, together with the billing-run reference. Follow Microsoft’s refresh request reference for the body supported by your identity and capacity; the notification option does not apply to service-principal operations.

Read the model’s refresh history and match the saved request identifier. Do not assume the most recent entry belongs to your application: a scheduled refresh or another caller may have started a different operation.

In Microsoft’s refresh history response, Completed means that refresh succeeded. Failed requires investigation of the error details. Unknown may mean processing is still underway or completion is not established. A successful HTTP response from the history request only means the history was retrieved.

If PBRS manages the reporting job

Prepare the report schedule in PBRS first. Select the customer’s report content, configure the required datasets under Refresh Datasets, and set the output and destination. Choose refresh notifications and failure handling deliberately, including whether a failed refresh raises an error.

Run that job from PBRS before connecting the API. Open the delivered statement, check its reporting period and confirm that it belongs to the intended customer. Once this works, the application can trigger the same configured routine after the billing load finishes.

Plan for the days that do not run smoothly

Poll at a reasonable interval and set a monitoring deadline. Reaching the deadline means your application stopped waiting; it does not prove the server stopped working. Keep the existing execution reference so the operator can investigate or resume monitoring.

If a submission times out before the application receives an identifier, check the server-side activity before submitting again. The first request may already be running. A blind retry could create a second statement or duplicate delivery.

Give the operator a useful failure message: whether the source load is missing, refresh failed, or report delivery needs attention. Include the billing reference and relevant execution identifier, while keeping access tokens and credentials out of routine logs.

The PBRS API starts the existing reporting job and gives your application an execution identifier to follow. Configure refresh and delivery in that job first; calling the execution endpoint does not add those settings automatically.

The distinction that matters here is between finishing and succeeding. PBRS can return a Completed execution whose result reports an error. Inspect the result before telling the accounts team that the statement is ready.

POST /api/Schedule/ExecuteScheduleAsync
Authorization: bearer <access-token>
Content-Type: application/json

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

GET /api/Schedule/GetExecutionStatus?ExecutionId=<returned-execution-id>
Authorization: bearer <access-token>

# $PbrsStatus is the response for the saved ExecutionId.
if ($PbrsStatus.Status -ne "Completed") {
    throw "Execution is not yet confirmed complete."
}

if ([string]::IsNullOrWhiteSpace($PbrsStatus.ResultJson)) {
    throw "No execution result was returned. Investigate."
}

$PbrsResult = $PbrsStatus.ResultJson | ConvertFrom-Json -ErrorAction Stop

if ($PbrsResult.Result -isnot [bool]) {
    throw "The result is missing the expected boolean Result field."
}

if (-not $PbrsResult.Result) {
    throw "PBRS reported an error: $($PbrsResult.ErrorMessage)"
}

Write-Host "PBRS reports success. Verify output and delivery."

Finally, confirm the expected file and destination. PBRS reporting success is useful execution evidence, but an email accepted for sending is not proof that it arrived in the customer’s inbox. Keep delivery checks appropriate to the destination and the promise your application makes.

When the customer calls again, the operator should be able to say which billing period the statement contains and whether its delivery has been confirmed. That is a more useful answer than knowing a refresh request was accepted.

Use the native API when model refresh is the task. When the work continues into customer selection, file preparation and delivery, PBRS lets you maintain that reporting process as a configured job and connect it to the application.

Explore the PBRS report automation API and the wider Power BI Report Automation workflow. Use the evaluation guide below to test one billing run from source readiness to its finished statement.

Download the PBRS Internal Evaluation Guide