Use the PBRS Postman Collection

Use the PBRS Postman collection to explore API requests, authenticate to your installation, and execute and monitor schedules.

The collection includes 81 requests. The environment template contains the variables used by the authentication and asynchronous execution workflow.

Download the files

Download both files:

• Download the PBRS API collection
• Download the PBRS environment template

If your browser displays JSON instead of downloading the file, use Save as to save it with its original .json filename.

Before you begin

You need:

• The Postman desktop app.
• A running PBRS API service.
• Network access to the PBRS API server.
• An enabled PBRS API client and its client ID and secret.
• Permission to perform the operations you intend to use.

For installation and connection setup, see Install and Configure the PBRS API.

Run requests individually. Running the entire collection can create, modify, execute, or delete schedules and change scheduler settings.

Import the collection and environment

1. Open your Postman workspace.
2. Select Import.
3. Import PBRS_API.postman_collection.json.
4. Import PBRS_Environment_Template.postman_environment.json.
5. Confirm that PBRS Public REST API appears under Collections.
6. Select PBRS Environment Template from the environment selector.

You can duplicate the environment and rename the copy for your installation.

Configure the environment

Open the environment and configure these variables:

Set the server address

The base URL must not end with /api or a trailing slash.

Use http://localhost:9000 only when Postman runs on the PBRS server and the API uses its default HTTP configuration.

For another server or an HTTPS deployment, enter that installation’s configured address.

The requests append their own endpoint paths. For example:

{{baseUrl}}/api/Service/Ping

The client-credentials token endpoint uses:

{{baseUrl}}/oauth2/token

Do not add /v1 to the base URL.

Enter credentials

Copy the client ID and secret from an enabled client in the API Clients tab of PBRS API Configuration.

Enter them in your local environment values. Keep credentials and tokens out of shared environments, exported files, screenshots, and repositories.

For authentication details, see Authentication and Token Management.

Check connectivity

Open Ping the API service under Service → Ping.

Send:

GET {{baseUrl}}/api/Service/Ping

A successful response is HTTP 200 with:

1

Ping uses No Auth. It confirms API connectivity; it does not confirm reporting-account access or successful report delivery.

Authenticate

Open Authenticate an API client under oauth2 → token.

The request uses No Auth and sends this JSON body:

{
  "grant_type": "client_credentials",
  "client_id": "{{client_id}}",
  "client_secret": "{{client_secret}}"
}

Send the request. On success, its After response script saves the returned token in the selected environment’s access_token variable.

The collection uses Bearer Token authentication with:

{{access_token}}

Authenticated requests inherit this setting. Ping and both token requests explicitly use No Auth.

Tokens expire after 60 minutes. Send Authenticate an API client again to obtain a new token. The collection does not automatically renew tokens.

The authentication script clears the previous stored token before saving a new successful result.

Execute an existing schedule

Choose a schedule whose output and destination are appropriate for your intended execution.

Set:

• schedule_id to the schedule’s numeric identifier.
• schedule_type to report for a single-report schedule or package for a package.

Open Queue a schedule asynchronously under Schedule → ExecuteScheduleAsync.

Its request body is:

{
  "ScheduleType": "{{schedule_type}}",
  "uniqueid": {{schedule_id}},
  "RunBy": "API"
}

The numeric variable is deliberately unquoted. Populate schedule_id before sending the request so that substitution produces valid JSON.

Sending this request starts work that can deliver email or write output files.

On successful submission, the After response script stores the returned ExecutionId in execution_id. It clears the previous stored execution identifier before capturing the new result.

A returned identifier confirms submission, not successful rendering or delivery.

Monitor execution

Open Get an execution status under Schedule → GetExecutionStatus.

The request uses:

{{baseUrl}}/api/Schedule/GetExecutionStatus?ExecutionId={{execution_id}}

Send the request to inspect the execution. Repeat as needed within a defined monitoring deadline.

Check the execution status and the result contained in the string-valued ResultJson field. A Completed status can contain a failed result.

Confirm the expected output and delivery separately. An empty or missing result is not evidence of success.

The collection does not automatically poll or retry execution requests.

For recovery and uncertain outcomes, see Monitor, Recover, and Reconcile Executions.

Use other requests

The remaining requests contain example identifiers and configuration values.

Before sending one:

1. Read its description and the corresponding API Reference entry.
2. Replace example identifiers, account settings, report paths, recipients, and destinations.
3. Review the request body and query parameters.
4. Confirm that you intend any documented side effects.

The environment variables do not automatically replace example values in every request.

Some documented GET operations require request bodies. Preserve the body where required by the operation.

For full schedule updates, include the complete intended destination collections and retain existing destination identifiers. Omitted destinations can be removed.

See Schedule Lifecycle Reference for operation-specific behavior.

Troubleshooting

For a complete PowerShell example, follow Authenticate, Execute, and Monitor a Schedule. The recipe covers authentication, asynchronous execution, polling with a time limit, and execution-result checks.

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.

For a complete PowerShell example, follow Update Email Recipients Without Changing Other Destination Settings. The recipe updates To recipients, preserves other destination settings, and verifies the saved changes without executing the schedule.

For a complete PowerShell example, follow Create a Report Package and Execute It. The recipe creates a package containing two Power BI reports, verifies the saved configuration, exports the reports as separate PDFs to a folder, and monitors the execution result.

For a complete PowerShell example, follow Create a Data-Driven Report Package. The recipe uses JSON rows to filter two Power BI reports by agent name, verifies the saved package configuration, sends all generated reports to one fixed email recipient, and monitors the execution result.

Next steps

Use Discover Folders, Reports, and Reporting Resources to obtain identifiers.

Use Create and Update Single Schedules to configure schedules.

Consult the API Reference for each operation’s complete request and response contract.