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

Create API Clients and Authenticate with the PBRS REST API

Use either a generated API client or an approved PBRS user account to obtain an access token.

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

Choose an authentication flow

Flow Use Token route Authorization header
OAuth 2.0 client credentials Server-to-server integrations POST http://[pbrsserver]:9000/oauth2/token Authorization: bearer {access_token}
PBRS username and password Approved user-context integrations POST http://[pbrsserver]:9000/api/login/token Authorization: token {access_token}

These are separate documented flows. They use different token routes, token response fields, and authorization schemes.

Client credentials flow

Create the API client in PBRS before requesting a token. PBRS automatically generates the client ID and client secret.

POST http://[pbrsserver]:9000/oauth2/token Content-Type: application/x-www-form-urlencoded  grant_type=client_credentials&client_id={client_id}&client_secret={client_secret}
{   "access_token": "{redacted}",   "token_type": "bearer",   "expires_in": 86399 }

Username and password flow

POST http://[pbrsserver]:9000/api/login/token Content-Type: application/x-www-form-urlencoded  username={username}&password={password}

The documented response includes UserId, FirstName, LastName, role, ExpiryDateEpoch, token, and token_type. Use the returned token value in the custom token authorization header.

Call a protected endpoint

Authorization: bearer {access_token}

Use bearer only for a client-credentials token. For a username-and-password token, use Authorization: token {access_token}. The public documentation identifies GET /api/service/ping as the only endpoint that does not require a token.

Token lifetime and secure handling

The public documentation states that tokens expire after 24 hours. An integration should request a new token when required, handle an expired or rejected token without logging credentials, and avoid requesting a new token for every API call.

  • Keep credentials and tokens on a trusted server.
  • Redact authorization headers and token responses from logs.
  • Use environment-specific credentials.
  • Rotate a secret immediately if it may have been exposed.
  • Do not send a PBRS access token to an end user's browser.

Authorization must be verified per operation

PBRS documents username/password token acquisition and OAuth 2.0 client credentials. Do not assume that every endpoint accepts both schemes or that both resolve PBRS permissions identically. The endpoint reference must record the accepted scheme and required PBRS role for every operation.

Client security checklist

  • Keep credentials and tokens on a trusted server, never in browser code.
  • Use separate clients for development, test and production.
  • Rotate secrets and revoke unused clients.
  • Cache tokens only for their documented lifetime and handle expiry explicitly.
  • Redact Authorization headers, credentials and tokens from logs and support bundles.

Authentication and authorization verification matrix

Operation family Username/password token OAuth client token Required PBRS role
Health and service status Validate by build; ping is documented as unauthenticated Validate by build Validate
Discovery and read operations Validate Validate Validate folder/account visibility
Execution and cancellation Validate Validate Validate execution permission
Create, update and delete Validate Validate Validate per schedule family
Scheduler and collaboration administration Validate Validate Administrator expected; confirm

Do not replace the validation cells with assumptions. Development must test every operation using both token types and a non-administrator role.

Separate PBRS API authentication from report-source authentication

A valid PBRS access token proves that the caller can reach the PBRS API. It does not prove that the configured Power BI or SSRS account can retrieve the source report. If an API-triggered execution fails after a Power BI password, service-principal secret, tenant policy, or token change, refresh and revalidate the Power BI account inside PBRS before changing the PBRS API client.

Previously working username/password flow fails

  • Confirm the exact /api/login/token route for the installed build.
  • Confirm form encoding and the custom Authorization: token scheme.
  • Test locally and remotely to separate endpoint, DNS and firewall failures.
  • Capture the build and sanitized response; support evidence records a route-related regression in a previously working flow.

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.