Update Paginated Report Parameters

Update the stored parameter values of an existing Power BI paginated report schedule without submitting a complete schedule definition.

Use this workflow when the report, recurrence, and destinations remain the same and only the parameters need to change.

For a complete PowerShell example, follow Update Paginated Report Parameters and Execute a Schedule. The recipe changes one named parameter, preserves the others, verifies the saved values, and executes and monitors the schedule.

Before you begin

You need:

• A running PBRS API service.
• A valid access token and permission to modify the schedule.
• The existing paginated schedule’s uniqueid.
• The parameter names, types, and values required by the report.

Send these headers:

Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json
Accept: application/json

The examples use schedule ID 101. Replace it with the ID from your environment.

Choose the correct operation

The parameter-specific operation requires only the schedule identifier and parameter collection. It does not require recurrence or destination collections.

Use the full update operation when changing the report configuration, recurrence, destinations, or other schedule settings.

Read the existing parameters

Retrieve the schedule before editing:

GET /api/SingleSchedule/GetPaginated?Id=101

Inspect its Parameters collection and confirm:

• The schedule references the intended report.
• Each parameter name matches the report parameter.
• Each parameter has the appropriate type.
• Existing parameter identifiers are preserved.
• Values that should remain unchanged are retained.

Use the parameter’s actual name, not its display prompt.

A schedule read returns stored configuration. It does not prove that a value remains valid after the underlying report or its available values have changed.

Parameter fields

Parameter types

ParameterValue remains a string for non-null values, including numeric and Boolean parameters.

For example, a numeric value is represented as:

{
  "ParameterName": "MinimumAmount",
  "ParameterValue": "1000",
  "ParameterType": 1,
  "IsNull": false
}

Match the value representation to the report’s requirements. For date parameters, avoid ambiguous date strings and verify the interpretation in the executing environment.

Do not use ParameterType: 4 as a substitute for determining the report’s actual parameter type.

Submit the update

POST /api/SingleSchedule/UpdateParametersPaginated

The request requires:

• A nonzero uniqueid.
• A Parameters array.

The following example assumes the schedule has one parameter named Region.

{
  "uniqueid": 101,
  "Parameters": [
    {
      "ParameterName": "Region",
      "ParameterValue": "West",
      "ParameterType": 0,
      "IsNull": false
    }
  ]
}

If the existing parameter has a ParameterId, include its actual value.

For schedules with additional parameters, build the intended collection from the existing configuration and retain the parameters that should remain unchanged. Do not rely on omission, an empty array, or a missing value as a preservation instruction.

Successful response

A successful request returns HTTP 200 with:

{
  "SuccessMessage": "Parameters updated successfully",
  "uniqueid": 101,
  "Parameters": [
    {
      "ParameterName": "Region",
      "ParameterValue": "West",
      "ParameterType": 0,
      "IsNull": false
    }
  ]
}

Unlike a complete paginated schedule update, this operation returns a JSON body.

The response confirms the parameter update operation. Retrieve the schedule separately to verify the saved values.

Send a null value

Use IsNull: true when the report parameter permits null.

For a schedule with only the Region parameter:

{
  "uniqueid": 101,
  "Parameters": [
    {
      "ParameterName": "Region",
      "ParameterValue": null,
      "ParameterType": 0,
      "IsNull": true
    }
  ]
}

Preserve the existing ParameterId when available and include any other parameters that should remain in the intended collection.

Keep these cases distinct:

Do not send the string "null" when you mean a null value.

Whether null or an empty string is valid depends on the report parameter.

Handle multiple values and dependent parameters

The paginated parameter model exposes a string ParameterValue. It does not expose a ParameterValues array or an IsMultiValue field.

Do not invent a comma-separated, semicolon-separated, or JSON-array encoding for multi-value parameters. Use the representation supported by the report and PBRS configuration, then verify it through read-back and execution.

If one parameter controls the available values of another, update the dependent values consistently. Saving a parameter collection does not establish that every combination will be accepted when the report executes.

Keep SSRS parameter models separate

SSRS parameter operations use a different model, including:

• ParameterValues, a string-to-string dictionary.
• IsMultiValue.
• SSRS-specific parameter metadata.

Do not copy that model into UpdateParametersPaginated.

Similarly, do not assume this endpoint updates package members or every report source simply because another model also contains a Parameters collection.

Send the request from application code

Build a structured request object and serialize it once.

For JSON requests:

• Keep Parameters as an array of objects.
• Keep non-null ParameterValue values as strings.
• Keep ParameterType as an integer.
• Keep IsNull as a Boolean.
• Preserve JSON nulls.
• Set Content-Type to application/json.

Do not serialize the complete request into a JSON string and then serialize that string again.

cURL example

Save the complete intended request body in parameter-update.json, then send:

curl --request POST "${PBRS_BASE_URL}/api/SingleSchedule/UpdateParametersPaginated" \
  --header "Authorization: Bearer ${PBRS_TOKEN}" \
  --header "Content-Type: application/json" \
  --header "Accept: application/json" \
  --data-binary @parameter-update.json

Set PBRS_BASE_URL to the service origin without a trailing /api, and set PBRS_TOKEN to a valid access token.

Using a request file avoids shell-escaping problems with quotes, backslashes, and parameter values.

Verify the saved configuration

Retrieve the schedule again:

GET /api/SingleSchedule/GetPaginated?Id=101

Compare the saved Parameters collection with the intended configuration.

Check:

1. Parameter names and identifiers.
2. Changed values.
3. Parameter types.
4. Null flags.
5. Parameters that should remain unchanged.

If the values differ, investigate before executing the schedule or submitting another update.

Execute a controlled test

Updating parameters changes stored schedule configuration. It does not execute the schedule.

To test the saved values:

POST /api/Schedule/ExecuteScheduleAsync

{
  "ScheduleType": "report",
  "uniqueid": 101,
  "RunBy": "API"
}

Retain the returned ExecutionId, then monitor:

GET /api/Schedule/GetExecutionStatus?ExecutionId=RETURNED_EXECUTION_ID

Parse ResultJson when it is populated. Completed does not necessarily mean success.

Inspect the generated report to confirm that the parameter values selected the intended data, and verify delivery to the controlled destination.

Coordinate updates with execution

Do not assume a parameter update changes an execution that is already running.

If the application requires a particular parameter set for a particular run:

1. Coordinate other writers and scheduled executions.
2. Read the current configuration.
3. Apply the intended parameters.
4. Verify the saved values.
5. Submit the execution.
6. Monitor and inspect its output.

The API does not make this sequence an atomic update-and-execute transaction. Concurrent updates or another scheduler action can affect the workflow.

Retain the requested parameter set alongside the execution record for troubleshooting and reconciliation.

Handle errors and retries

The operation can return HTTP 500 for authentication, permission, input, database, or other processing failures. Error details can vary.

Do not treat every 500 response as transient.

After a timeout or lost connection:

1. Retrieve the schedule.
2. Inspect the stored parameters.
3. Determine whether the update was applied.
4. Reconcile the intended and actual values before retrying.

A failed client request does not prove that no configuration changed.

Troubleshooting

For broader diagnostics, see Troubleshoot API Integrations.