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

Install and Configure the PBRS REST API

Install the API Windows service, start it, and prepare network access for an approved integration.

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

Before you begin

  • Administrator access to the PBRS server.
  • A working PBRS installation.
  • Windows credentials for the account that will run the API service.
  • An approved network path from the calling system to the PBRS server.
  • A secure location in which to store the generated client secret.

Install and start the API service

  1. Open PBRS on the server.
  2. Open Options.
  3. Select REST API.
  4. In API Status, select Install API.
  5. Enter the Windows credentials that the API service will use.
  6. When prompted, approve opening port 9000 only if that rule is appropriate for the network design.
  7. Return to API Status and select Start.

The API is installed as a Windows service. The public documentation uses port 9000 and the default base address http://[pbrsserver]:9000/api.

Create an API client

  1. In the API Clients area, select Add.
  2. Enter a descriptive client name that identifies the calling application and environment.
  3. PBRS generates the client ID and client secret.
  4. Store the client ID and secret in an approved secret store.
  5. Save and close the configuration.

Important: Do not place the client secret in client-side JavaScript, a desktop shortcut, a shared spreadsheet, source control, or a support ticket.

Verify the installation

  1. Confirm that the PBRS API Windows service is running.
  2. From the calling machine, verify that the approved server name resolves and that the configured port is reachable.
  3. Call GET /api/service/ping. The documented success value is 1.
  4. Obtain a token using the selected authentication flow.
  5. Call a protected read-only operation to confirm authentication.

Production deployment checklist

  • Limit inbound access to approved calling systems.
  • Use a separate API client for each integration and environment where practical.
  • Document the service account, server, port, firewall owner, certificate owner, and recovery procedure.
  • Monitor both the API service and the PBRS scheduler service.
  • Confirm the supported HTTPS, certificate, reverse-proxy, and alternate-port configuration with Development for the installed build.

Production deployment checklist

  1. Confirm the supported PBRS build and Windows prerequisites.
  2. Verify the PBRS API executable, service files and configuration are present after installation or upgrade.
  3. Run the service under an approved least-privilege account and record service dependencies.
  4. Bind only the required interface and port; restrict inbound access with host and network firewalls.
  5. Use the Development-approved HTTPS topology and certificate-renewal owner.
  6. Test token acquisition locally, then from the approved remote integration host.
  7. Retest authentication, discovery, execution and one controlled delivery after every upgrade.

Do not publish a direct-HTTPS or reverse-proxy recipe until Development has validated certificate binding and supported topology.

Installation and upgrade recovery

  1. Record the existing installation drive, PBRS build, API service identity, startup type, base URL, port and certificate topology.
  2. After installation or upgrade, confirm that PBRSAPI.exe and the required API service and configuration files are present in the PBRS API directory.
  3. If the service is absent or cannot start, do not manually copy files from another build. Re-run the supported installer or upgrade procedure and verify the registered service path.
  4. Confirm database connectivity and any Windows service dependencies before restarting integrations.
  5. Run a synthetic test: local ping, remote ping, token request, protected read, controlled asynchronous execution and controlled delivery.
  6. Retain the previous validated configuration and rollback procedure until regression testing passes.

Support evidence: API outages have followed upgrades in which the executable was deleted or not replaced, and installations made to a different drive have left services pointing to missing files. The exact repair procedure and supported installer behavior must be confirmed for each maintained build.

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.