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

Update Paginated Report Parameters with the PBRS REST API

Update parameter values on an existing paginated schedule and verify the saved and rendered result.

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

Operation

POST /api/singleschedule/updateparameterspaginated

This operation is evidenced in authorized support records. Development must confirm the first supported build, accepted authentication schemes, required PBRS permission, canonical request schema and success/error responses before publication.

Safe workflow

  1. Retrieve the target paginated schedule and confirm its identity.
  2. Build the parameter collection using the validated field names and types.
  3. Serialize the request as JSON using the required content type.
  4. Submit the request from a non-production environment.
  5. Retrieve the schedule again and compare the persisted parameter values.
  6. Execute the schedule with controlled output and recipients.
  7. Verify the rendered report and destination delivery.

When Postman works but application code fails

Capture sanitized raw requests from both clients and compare content type, URL, method, field casing, wrapper objects, array nesting, JSON escaping, nulls, dates, booleans and multi-value parameters. Compare the final wire representation, not only the in-memory object.

Example placeholder

Add copy-ready cURL, PowerShell and C# examples only after Development supplies and tests the canonical model. Do not infer the schema from a screenshot or a single failing client.

Support-evidenced request structure

{   "UniqueId": 796737122,   "Parameters": [     {       "ParameterName": "businessStartDate",       "ParameterValue": "2025-04-01",       "IsNull": false,       "ParameterType": 2     }   ] }

Replace the identifier and parameter with values from a non-production schedule. The field structure is evidenced by a successful support workflow; Development must still confirm date serialization, accepted wrappers, multi-value behavior, response schema and current-build compatibility.

Known verification evidence

  • Support records show paginated parameter updating working after an April 2025 product update.
  • A build 20250402 support test used the username/password login token successfully for the update operation.
  • The same logical request worked in Postman but failed in C# until the Newtonsoft serialization produced the expected JSON shape.

These observations belong in the validation ledger; they do not prove OAuth support or compatibility with every later 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.