PBRS REST API Overview

The PBRS REST API connects your applications to your PBRS installation. Use it to discover reporting resources, create and update schedules, execute reports, manage report packages, and monitor execution.

Supported reporting sources include Power BI Service reports, Power BI Paginated Reports, SQL Server Reporting Services (SSRS), and Power BI Report Server (PBIRS). Available operations vary by report source and schedule type.

How the API works

The API runs as a Windows service on your PBRS server. Your application sends authenticated requests to that service, and PBRS performs the requested operations using your installation's configured reporting accounts, schedules, and destinations.

Install the service from PBRS → Options → REST API → Install API. Configure its protocol and port, start the service, and verify connectivity before making authenticated requests.

Your application must be able to reach the PBRS server. The reporting accounts and destinations used by your workflow must also be accessible to the PBRS installation.

What you can do

Consult the API Reference for the exact fields, responses, and supported behavior of each operation.

A capability available in the PBRS desktop application does not automatically have an equivalent public API operation. Similarly, an operation supported for one schedule type may not apply to another.

Before you begin

You need:

• A working PBRS installation with its REST API service installed and running.
• The API server address, protocol, and port.
• Network access from your application to the PBRS API service.
• An enabled API client or a PBRS user account for authentication.
• Reporting accounts and destination configuration appropriate to your workflow.
• Permission to perform the required operations.

For your first execution test, use an existing schedule with a known report and a controlled delivery destination. Confirm that it runs successfully from PBRS before executing it through the API.

Connect to your installation

The base address consists of your configured protocol, host, and port:

{scheme}://{host}:{port}

The default local HTTP address is:

http://localhost:9000

localhost refers to the machine making the request. If your application runs on another machine, use the PBRS server's reachable hostname or IP address.

For HTTPS, configure the server certificate and Windows certificate binding before connecting. Use a hostname that matches the certificate and the port configured for your installation.

Base address and endpoint paths

Keep /api out of the base address, then append the complete endpoint path.

Most endpoint paths begin with /api, but the client-credentials token endpoint does not.

The API version label is v1. Do not add /v1 to endpoint paths.

Authenticate your application

PBRS supports two authentication methods:

For client-credentials authentication, create and enable the client in the API Clients tab of PBRS API Configuration.

Windows credentials entered during API service installation are separate from these application authentication credentials.

After obtaining a token, include it in the Authorization header with the bearer prefix.

• Tokens expire after 60 minutes.
• Incorrect credentials return HTTP 401 Unauthorized.
• Ping does not require a token.
• Permissions can further restrict access to individual operations.

Store credentials and tokens in your server-side application or an appropriate secret store. Do not expose them in browser-delivered code or public repositories.

Your first API workflow

Start with an existing schedule:

1. Check connectivity. Call Ping to verify that the API service is reachable.
2. Authenticate. Obtain a token using your selected authentication method.
3. Identify the schedule. Obtain the identifier of a schedule you are authorized to execute.
4. Submit execution. Call ExecuteScheduleAsync and retain the returned ExecutionId.
5. Monitor progress. Poll the execution-status operation within a defined time limit.
6. Verify the outcome. Inspect the execution result and confirm the expected output and delivery.

A successful HTTP request or accepted execution does not prove that the report rendered or reached its destination.

Schedule identifiers, ExecutionId, and ProcessId serve different purposes. Use the identifier required by each operation; they are not interchangeable.

Use the API Reference

Each operation's reference page describes its HTTP method, path, authentication, parameters, request format, and responses.

Use the exact field names and content type specified for that operation.

GET requests with bodies

Some operations require a request body with a GET request. Their reference pages provide cURL examples and body details.

Interactive request buttons are disabled for these operations because OpenAPI 3.0 clients do not consistently support GET request bodies. Use a documented POST alternative where one is available.

Generated clients may require custom handling for GET requests with bodies.

Build reliable integrations

Preserve configuration during updates

Some update operations replace collections or remove omitted destinations. Follow the operation-specific update rules and preserve the settings your application intends to keep.

Reconcile before retrying

A timed-out request may already have created a schedule or submitted work. Check the resulting state before repeating the request.

Bulk operations can leave earlier items in place if a later item fails. Do not assume automatic rollback or that repeating a request is safe.

Plan for execution capacity

PBRS does not throttle API requests. However, configured execution concurrency, server resources, and upstream reporting-service limits still affect processing.

Set appropriate request timeouts and polling intervals, and verify execution outcomes separately from request acceptance.

Where to go next

Follow these guides in order:

1. Install and Configure the PBRS API — Install the service, configure its connection settings, create a client, and test connectivity.
2. Authentication and Token Management — Obtain a token and authenticate subsequent requests.
3. Quick Start: Execute and Monitor a Schedule — Submit an existing schedule, monitor execution, and verify the result.

Use Schedule Lifecycle Reference to compare schedule operations, identifiers, and side effects.

Use SSRS and Power BI Report Server Integration for source-specific connections, parameters, schedule creation, and updates.

Explore the remaining guides for report personalization, package processing, migration, and operational troubleshooting. Consult the API Reference for each operation’s request fields, responses, and supported behavior.