Schedule Lifecycle Reference

Use the PBRS API to create, inspect, update, clone, rename, enable, disable, execute, and delete schedules.

Choose the operation for the report source and schedule family. Keep schedule configuration changes separate from execution monitoring and cancellation.

Before you begin

You need:

• A running PBRS API service.
• The base URL configured for your deployment.
• A valid access token.
• An account with permission to perform the requested operation.
• The schedule identifier and its report source or schedule family when working with an existing schedule.

Send authenticated requests with:

Authorization: bearer YOUR_ACCESS_TOKEN
Accept: application/json

For JSON request bodies, also send:

Content-Type: application/json

All paths below are relative to your configured base URL. Replace example identifiers with identifiers from your PBRS environment.

Identify the schedule and operation

PBRS uses different identifiers for stored schedules, execution records, and running processes.

A schedule identifier is not an execution identifier. Multiple executions of the same schedule can have different ExecutionId values.

Schedule type selectors

Shared execution requests use ScheduleType to identify the schedule family.

The selector describes the schedule family, not the report source. For example, report does not distinguish Power BI from SSRS.

A selector accepted by an execution request does not establish that every create, update, clone, or delete operation supports that family. Use the operation-specific request schema.

Create, read, and update schedules

Choose the routes that match the report source.

Preserve the route spelling shown above.

POST /api/Package/Create is also available. It is a separate operation with different controller validation. Do not switch between package creation routes as an automatic retry strategy.

Create a schedule

Submit a complete definition using the selected creation operation. Include the required account or connection settings, report identifiers, recurrence, rendering options, parameters or filters, and destinations.

Successful creation returns an object containing the new schedule identifier:

{
  "uniqueid": 101
}

Store this identifier and retrieve the schedule using the matching read operation.

A successful creation response confirms that the schedule was created. It does not confirm that the report can render or that delivery will succeed.

Before enabling recurring execution, verify the saved configuration and perform a controlled execution with the intended account and destinations.

Update a schedule

Full update operations require the existing schedule's uniqueid and the complete intended definition.

Before submitting an update:

1. Retrieve the current schedule using the matching read operation.
2. Compare it with the configuration maintained by your integration.
3. Preserve all settings that must remain in effect.
4. Apply the intended changes.
5. Submit the complete definition.
6. Retrieve the schedule again and verify the changes.

Do not assume that a read response can be submitted unchanged as an update request. Read models may omit writable settings or expose them in a different form.

For example, ClientRenderingSettings is not a replacement for the writable RenderingSettings field.

Preserve destinations and filters

For full single-schedule and package updates:

• Include both EmailDestinations and DiskDestinations as non-null arrays.
• Include every destination that should remain.
• Preserve the existing DestinationId for each destination you retain.
• Use [] only when the corresponding destination collection should be empty.

Existing destinations omitted from these lists are removed. Omitting a collection is not an instruction to preserve it and can cause the update to fail.

Power BI full updates also clear and rebuild filters. Include every filter that should remain.

Preserve the intended recurrence, enabled state, rendering settings, parameters, report collections, and connection settings.

Handle update responses

Do not attempt to parse an empty successful response as JSON.

The package update response echoes the submitted model. Retrieve the package separately to verify persisted values.

For a parameter-only change to a paginated schedule, use:

POST /api/SingleSchedule/UpdateParametersPaginated

Supply a nonzero uniqueid and the intended Parameters collection. This operation does not require a complete schedule replacement.

Rename a schedule

Use:

POST /api/Schedule/RenameSchedule

Example request:

{
  "ScheduleType": "report",
  "uniqueid": 101,
  "ScheduleName": "Daily Sales"
}

ScheduleName is required and must contain between 1 and 255 characters.

A successful response is HTTP 200 with an empty body. Retrieve the schedule afterward to verify the name.

Renaming an existing schedule does not create a new schedule identifier.

Disable or enable scheduled execution

Disable a schedule

Use:

POST /api/Schedule/DisableSchedule

Example request:

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

Disabling a schedule prevents future scheduled execution. It does not cancel an execution that is already running.

Enable a schedule

Use:

POST /api/Schedule/EnableSchedule

Example request:

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

For a package, use ScheduleType: "package" and its schedule identifier.

Both operations return HTTP 200 with an empty body on success.

Verify the recurrence, next run, destinations, and saved settings before enabling a schedule.

Clone a schedule

A successful clone returns the new identifier as a JSON number:

102

This response is not an object containing uniqueid.

Although cloning uses GET, it changes stored data. Prevent automatic retries, prefetching, or other client behavior that could create additional copies.

After cloning:

1. Store the new identifier.
2. Retrieve the cloned schedule.
3. Inspect its name, enabled state, recurrence, report references, and destinations.
4. Make any required changes before allowing it to run.

Do not assume that a clone is disabled or that its destinations are suitable for a test execution.

Execute a schedule

Choose the execution mode deliberately.

For a standard asynchronous execution:

POST /api/Schedule/ExecuteScheduleAsync

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

Retain the returned ExecutionId and query:

GET /api/Schedule/GetExecutionStatus?ExecutionId=YOUR_EXECUTION_ID

A returned execution identifier acknowledges submission. It does not confirm successful rendering or delivery.

When checking status:

• Use bounded polling.
• Inspect Status and parse the string-valued ResultJson separately.
• Check the execution result even when Status is Completed.
• Do not interpret an empty result as success.
• Confirm delivery at the intended destination.

For synchronous execution, inspect Result even when the HTTP request succeeds.

Use ExecuteScheduleOnTimeAsync only when advancing the next scheduled run is intended.

Cancel or terminate an execution

Cancellation and termination affect an execution or process. They do not replace schedule disabling or deletion.

These GET operations change server state.

Cancellation depends on finding the execution's process. A waiting execution without a live process is not guaranteed to be removed by CancelExecution.

Before terminating a process, verify that the process identifier belongs to the intended execution on the correct server.

Neither operation reverses files already written or messages already delivered. Verify the resulting execution state and destination activity before retrying.

Delete a schedule

The caller must have permission to modify schedules.

A successful deletion returns a JSON boolean:

true

Before deleting:

1. Verify the schedule identifier and report source or family.
2. Preserve any configuration needed for recovery or migration.
3. Review package membership and other references to the schedule.
4. Disable future scheduled execution.
5. Check for active executions and handle them separately.
6. Delete the intended schedule and verify the outcome.

Do not assume that deleting a schedule cancels active executions, deletes related schedules, or removes previously delivered output.

Create schedules in bulk

Bulk creation is available for:

POST /api/SingleSchedule/CreateMultipleForPaginated

POST /api/SingleSchedule/CreateMultipleForSSRS

Supply an array of complete definitions. On success, the response contains numeric identifiers in input order:

[
  101,
  102
]

These operations validate the input and create schedules sequentially. A later failure can leave earlier schedules saved.

A failed batch does not provide a guaranteed rollback or a reliable list of every schedule already created. Reconcile the stored schedules before resubmitting any items.

Recover from an uncertain outcome

A timeout or lost connection does not prove that PBRS rejected the request.

Before retrying a creation, clone, import, update, or execution request:

1. Check whether the intended change or execution already occurred.
2. Retrieve the relevant schedule or execution record when its identifier is available.
3. Compare persisted state with the intended change.
4. Retry only after resolving the earlier outcome.

The API does not expose an idempotency-key contract for preventing duplicate execution submissions. An execution correlation value must not be treated as duplicate protection.

For updates, compare the current definition before resubmitting so that a retry does not overwrite an intervening change.

Other schedule families

The shared execution interface includes selectors for automation, event-based schedules, and event-based packages.

Those selectors do not imply dedicated public creation or full-update routes for every family. Use the documented import workflow or the PBRS application where the API does not expose the required authoring operation.

For background on execution modes and schedule-family selectors, see Executing schedules with the PBRS API.