Skip to content
  • There are no suggestions because the search field is empty.

Create and Update Power BI and Paginated Report Schedules with the PBRS API

Create supported Power BI and paginated-report single schedules and make validated updates.

Review status: Draft for Development and Support review. Routes and models labelled validation required must be tested against the supported PBRS build before publication.

Documented single-schedule operations

Task Documented route Status
List Power BI schedules GET api/singleschedule/getall Documented
List paginated schedules GET api/singleschedule/getallpaginated Documented
Get Power BI schedule GET api/singleschedule/get/{id} Documented
Get paginated schedule GET api/singleschedule/getpaginated/{id} Documented
Create Power BI schedule POST api/singleschedule/createforpowerbi Documented
Create paginated schedule POST api/singleschedule/createpaginated Documented
Bulk-create paginated schedules Canonical route pending Public URL is malformed
Update Power BI schedule POST api/singleschedule/updateforpowerbi Documented
Delete single or paginated schedule Not established by reviewed public reference Do not publish until confirmed

Create a Power BI schedule

The documented model combines the report identity, optional bookmark, rendering settings, filters, schedule metadata, recurrence, and one or more email destinations.

  • PowerBiAccountId
  • ReportUrl
  • PowerBiReportName
  • WorkspaceName
  • ApplyBookmark and BookmarkJson
  • RenderingSettings
  • BasicFilters and AdvancedFilters
  • ScheduleName and FolderPath
  • Description and Keywords
  • Schedule
  • EmailDestinations

Create a paginated-report schedule

The documented paginated model includes PowerBiAccountId, ReportUrl, PowerBiReportName, WorkspaceName, UseNativeAPIForRendering, and an array of PaginatedParameterModel values. Development must confirm the complete shared scheduling and destination fields expected by this operation.

Update safely

  1. Retrieve the current schedule model.
  2. Confirm the server, folder, name, type, and UniqueId.
  3. Apply only the intended changes.
  4. Submit the supported update request.
  5. Retrieve the schedule again and compare the saved result with the intended model.
  6. Run a controlled test when the change affects rendering or delivery.

The public reference states that UpdateForPowerBI uses the same body as CreateForPowerBI. A dedicated paginated-parameter update operation was not found in the reviewed public reference and must remain outside the published guide unless Development confirms it.

Prevent duplicates

  • Resolve the target folder before creating.
  • Search by path, name, type, and controlled keywords.
  • Use a deterministic external correlation value in your integration where practical.
  • After a timeout, retrieve PBRS state before retrying a create request.
  • Never retry a write blindly.

Update parameters on an existing paginated schedule

Support evidence records the following operation:

POST /api/singleschedule/updateparameterspaginated

The request updates the parameter values associated with an existing paginated schedule. The precise request schema, supported parameter types, null and multi-value behavior, response contract, permissions and first supported build must be validated before publication.

Safe update sequence

  1. Retrieve and identify the existing paginated schedule.
  2. Serialize the parameter collection exactly as required by the validated request model.
  3. Submit the update from a non-production client first.
  4. Retrieve the schedule again and compare the saved parameter state.
  5. Execute a controlled run and verify the rendered artifact and delivery.

When a request works in Postman but fails in application code, compare the raw content type, field casing, JSON nesting, escaped values and null handling byte for byte.

Minimum documented Power BI schedule structure

{   "PowerBiAccountId": "{account-id}",   "ObjectType": "REPORT",   "ReportUrl": "{embed-url}",   "PowerBiReportName": "{report-name}",   "WorkspaceName": "{workspace-name}",   "ApplyBookmark": false,   "BookmarkJson": "",   "RenderingSettings": { "RenderingMethod": 1 },   "BasicFilters": [],   "AdvancedFilters": [],   "ScheduleName": "API validation schedule",   "FolderPath": "{validated-folder-path}",   "Schedule": { "Enabled": false, "Frequency": "Daily", "StartDate": "2026-09-12", "ExecutionTime": "14:00" },   "EmailDestinations": [] }

This example shows the documented object hierarchy, not a guaranteed minimum body. Development must confirm required fields, whether an empty destination array is accepted, recurrence defaults and the expected content type before publication.

Recurrence must be validated by frequency

Frequency Known base fields Missing contract
Daily/Weekdays StartDate, ExecutionTime, Enabled, optional end/repeat fields Time-zone and missed-run behavior
Weekly Base fields Required day-of-week field and enum
Monthly Base fields Day-of-month/ordinal rules and invalid-date behavior
Annual Base fields Required month/day fields and leap-year behavior

A weekly schedule can be accepted without becoming runnable when its required day selection is absent. Read the schedule back and confirm NextRunEpochUtc before enabling it.

Bulk and SSRS authoring

The published material claims bulk paginated creation and creation of multiple SSRS single schedules from a JSON file. Support records also show a bulk-insert defect corrected in a later version. Until Development supplies the canonical routes and schemas, document these as build-dependent capabilities only. The final contract must define file versus request body, maximum batch size, duplicate behavior, atomicity, per-item results and safe rerun behavior.

Documentation standard: Record the PBRS build used for verification, test in a non-production environment, redact credentials and customer data, and confirm the saved PBRS state after every write.