PBRS REST API Version History
Track API additions, fixes, deprecations and documentation verification by PBRS build.
Review status: Draft for Development and Support review. Routes and models labelled validation required must be tested against the supported PBRS build before publication.
How to maintain this history
For every supported build, record the release date, added or changed endpoints, request and response changes, permission changes, fixes, deprecations, breaking changes and required client action. Link each item to the relevant endpoint and model entry.
Known documented milestone
| PBRS build | API change | Client action |
|---|---|---|
| 20250924 | Email-destination update and delete operations, plus clear-existing behavior | Review destination replacement logic and test preservation, update, deletion and delivery |
Verification ledger
Each endpoint and model article should show Introduced in, Last verified with PBRS build, Deprecated in where applicable, and a link to the regression test that passed. A support observation is evidence to investigate; it is not a version guarantee.
Before upgrading
- Compare the installed build with this history.
- Review authentication, recurrence, destination and rendering changes.
- Run the maintained contract and delivery regression suite.
- Validate service files and configuration after upgrade.
- Keep rollback instructions and the previous verified configuration.
Evidence and compatibility ledger
| Build/date | Evidence | Documentation treatment |
|---|---|---|
| April 2025 / build 20250402 evidence | Paginated-parameter update tested through the login-token flow | Development must confirm introduced build and current support |
| Build 20250924 | Email-destination clear-existing, update and delete changes | Publicly documented milestone |
| September 2025 support observation | Upgrade could remove PBRSAPI.exe without replacement |
Add installer-integrity regression test; not an API feature |
| 2025 support observations | Token-route regression, raw server errors, Chromium resource pressure and completion without delivery | Track fixes only after Development supplies exact builds |
| 2026 support observations | Current queue UI can terminate jobs; multi-server lab validated with Round-Robin | Confirm released build, permissions and limitations before public guarantee |
Required compatibility fields
Every endpoint must record: first supported build, last verified build, accepted token schemes, required PBRS role, content type, breaking changes, deprecated build and replacement. Every model must record field additions, default changes and enum changes. Every published example must identify the build used for its regression test.
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.