Skip to content
English
Log a Support Call Customer portal
  • There are no suggestions because the search field is empty.

Troubleshoot the PBRS REST API

Diagnose connectivity, authentication, request, execution, rendering, and delivery problems when integrating with the PBRS REST API.

Use this article to identify whether a PBRS REST API problem is caused by connectivity, authentication, request formatting, execution, report rendering, or delivery. Diagnose one layer at a time and record the request, response, schedule identifier, and execution identifier before retrying.

Start with the smallest diagnostic sequence

  1. Call GET /api/Service/Ping from the PBRS server.
  2. Call the same endpoint from the system running the integration.
  3. Request a new access token using the correct authentication flow.
  4. Call a protected read-only endpoint.
  5. Resolve the target folder or schedule again.
  6. Execute a controlled schedule asynchronously.
  7. Check its status and the API Execution Queue.
  8. Verify report rendering and delivery separately.

The API cannot be reached

  • Confirm that the PBRS API Windows service is installed and running.
  • Verify the server name, protocol, configured port, and base URL.
  • Check DNS resolution, routing, firewall rules, certificates, and any proxy or load balancer.
  • Test the Ping endpoint locally on the PBRS server before testing from another computer.
  • For HTTPS problems, compare the deployment with the documented certificate and binding procedure.

Authentication fails

  • Confirm that the token request uses the correct authentication flow and token endpoint.
  • Verify the client ID and client secret without placing either value in logs or screenshots.
  • Confirm that the token request uses the required content type and request format.
  • Request a fresh token if the existing token has expired or has been rejected.
  • Send the access token using the authorization scheme documented for that authentication flow.

A request is rejected

Use the HTTP status, response body, and API documentation together. The following checks cover the most common causes:

  • 400: Compare the request body, query parameters, property names, casing, and value types with the API Reference.
  • 401: Obtain a fresh token and verify the authorization header.
  • 404: Verify the base URL, route, object identifier, and installed PBRS API version.
  • 500: Record the sanitized request, response, and timestamp, then review the PBRS logs.

Depending on the endpoint, PBRS configuration, and any intervening proxy or web server, you may encounter additional HTTP status codes. Use the response body and the endpoint’s API Reference entry to identify the cause.

Postman works but application code fails

  • Compare the exact URL, route casing, HTTP method, headers, content type, and serialized body.
  • Confirm whether the operation expects form fields, query parameters, or JSON.
  • Check property names and casing, especially UniqueId and ExecutionId.
  • Confirm that variables do not contain a trailing slash, duplicated /api segment, whitespace, or an environment-specific value.
  • Compare the application request with the working request from the PBRS Postman collection.

An execution remains waiting or takes too long

  • Confirm that the PBRS Scheduler service is running.
  • Check available execution capacity and the API Execution Queue.
  • Locate the execution by its ExecutionId, schedule ID, submission time, and RunBy value.
  • Test the schedule directly in PBRS.
  • Review report-source availability, authentication, rendering time, filters, parameters, and destination connectivity.
  • Reduce concurrency and poll at a controlled interval rather than submitting the schedule again.

An execution completes but output is missing

  • Review the execution result for an error.
  • Check the schedule History record and PBRS Error Log.
  • Confirm that the expected report was rendered.
  • Verify that the intended destination is enabled and correctly configured.
  • Check recipients, paths, credentials, permissions, available storage, and the selected output format.
  • Inspect the relevant email, retry, or delivery queue.

Reconcile before retrying

A retry can create duplicate emails, files, or deliveries. Before resubmitting the schedule:

  • Record the original ExecutionId.
  • Check the API Execution Queue and schedule History.
  • Inspect the expected destination.
  • Determine whether rendering or delivery already occurred.
  • Retry only after confirming that another submission will not create an unwanted duplicate.

Information to provide to Support

  • PBRS version and API build.
  • Operation, endpoint, and timestamp.
  • Sanitized request and response.
  • Schedule name, type, folder path, UniqueId, and ExecutionId.
  • Relevant PBRS log excerpt.
  • Steps required to reproduce the problem in Postman.

Remove passwords, access tokens, client secrets, connection strings, recipient data, and confidential report content before sharing diagnostic information.

Detailed API documentation

Use the following Developer Hub resources for endpoint-level details: