Discover PBRS Accounts Reports Folders Visuals and Schedules
Resolve PBRS and report-source objects before creating or executing schedules.
Review status: Draft for Development and Support review. Routes and models labelled validation required must be tested against the supported PBRS build before publication.
Why discovery matters
Identifiers can differ between development, test, and production. Resolve objects in the target environment instead of copying IDs from another server or relying on display names alone.
Traverse PBRS folders
| Operation | Documented route | Purpose |
|---|---|---|
| Get folder | GET api/folder/get/{id} | Return a folder by ID. |
| Get subfolders | GET api/folder/getsubfolders/{id} | Return child folders. |
| Get schedules | GET api/folder/getschedules/{id} | Return schedule IDs, names, types, data-driven flags, and enabled state. |
| Resolve schedule | POST api/folder/getuniqueidfrompath | Resolve UniqueId from Path, ScheduleName, and ScheduleType. |
| Resolve folder | POST api/folder/getfolderfrompath | Return the folder object for a PBRS path. |
Discover Power BI content
- List configured accounts with GET api/powerbiaccount/getall.
- List workspaces with GET api/powerbiaccount/getworkspaces/{id}.
- Use the validated GetReports or GetDashboards request for the selected account and workspace.
- For a Power BI report, use the validated GetVisualsForReport request to resolve visual titles and zero-based page indexes.
- For paginated reports, use the corrected discovery route supplied by Development.
Validation required: The current public page labels GetVisualsForReport as GET but describes a POST body, and its GetPaginatedReports example points to the scheduler-stop route. Those literal examples must not be copied until corrected.
Discover SSRS accounts
GET /api/ssrsaccount/getall returns the SSRS accounts configured in PBRS. Development must provide the complete response schema and any follow-on SSRS report discovery operations before they are documented as a public contract.
Filter existing schedules by keyword
The documented single, paginated, and package list operations accept FilterValues, FilterOperator, and MatchType.
| Field | Values | Meaning |
|---|---|---|
| FilterValues | Array of strings | Values to match against schedule keywords. |
| FilterOperator | LIKE, NOT LIKE, =, <> | Comparison applied to the keyword values; the documented default is LIKE. |
| MatchType | ALL or ANY | Whether every supplied value or any supplied value must match. |
The public documentation says that omitting the request body returns an empty array. Confirm this behavior before designing a client that expects an unfiltered list.
Discovery implementation rules
- Persist PBRS identifiers returned by discovery rather than relying on display names alone.
- Treat duplicate names as ambiguous and resolve by account, workspace or folder path.
- Cache slowly changing discovery data, but refresh before destructive or security-sensitive changes.
- Handle empty and partial results explicitly.
- Do not invent pagination, GET-body or batch behavior; use only the contract verified for the deployed build.
The current public reference contains inconsistencies for some visual and paginated discovery operations. Keep those operations labelled validation required until tested.
Discovery operation checklist
| Resource | Operation | Contract status |
|---|---|---|
| PBRS folders | GET /api/folder/get/{id}, getsubfolders/{id}, getschedules/{id} |
Published; verify build |
| Paths | POST /api/folder/getuniqueidfrompath, getfolderfrompath |
Published; verify body/content type |
| Power BI accounts | GET /api/powerbiaccount/getall, getworkspaces/{id} |
Published |
| Reports and dashboards | getreports, getdashboards |
Published GET-with-body contract requires validation |
| Visuals | getvisualsforreport |
Published method/body conflict |
| Paginated reports | Development must supply corrected route | Published route is incorrect |
| SSRS accounts | GET /api/ssrsaccount/getall |
Published; follow-on discovery unknown |
Refresh upstream account metadata after credential changes
If discovery or execution stops working after a Power BI credential or token change, revalidate the configured Power BI account in PBRS and repeat account, workspace and report discovery. A successful PBRS API token does not refresh the upstream Power BI account.
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.