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

Manage Email Destinations and Output Settings

Add, replace, update, and delete email destinations for supported PBRS single schedules.

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

Destination operations

Task Documented route
Add an email destination POST api/singleschedule/addemaildestination?clearExisting=true
Update an email destination POST api/schedule/UpdateEmailDestination
Delete an email destination POST api/schedule/DeleteEmailDestination?destinationId={id}

Confirm whether clearExisting should be true or false before calling AddEmailDestination. A true value can replace existing destination configuration and must not be used as a default without understanding the side effect.

Documented email destination fields

  • ParentId, DestinationName, and Enabled.
  • To, Cc, and Bcc recipient arrays.
  • Subject and Body.
  • BodyFormat with documented HTML or TEXT values.
  • EmbedReport and EmbedFormat with documented IMAGE or HTML values.
  • CustomSenderName and the documented custom reply-to address property.
  • OutputFormat, CustomOutputFileName, and CustomOutputExtension.

Documented output-format labels

  • Acrobat Format (*.pdf)
  • HTML (*.html)
  • PNG (*.png)
  • JPG (*.jpg)
  • PowerPoint (*.pptx)
  • MS Excel (*.xlsx)
  • MS Word (*.docx)
  • MS Word (*.doc)
  • Epub (*.epub)

Scope: These are the output labels currently listed for the public EmailDestinationModel. Do not add CSV or other PBRS formats to this API article until the API contract confirms them for this destination model.

Safe update procedure

  1. Retrieve and record the schedule and destination IDs.
  2. Confirm the environment and destination name.
  3. Apply the smallest required change.
  4. Use controlled recipients while testing.
  5. Retrieve or inspect the saved destination after the update.
  6. Execute the schedule and verify the message, attachment, filename, sender, and embedded content.

Example update body

{   "DestinationId": 810811158,   "Subject": "Updated Monthly Sales Report",   "To": ["test-recipient@example.com"],   "Body": "Updated email body content" }

Example data: Replace every example identifier and address. Never test with production recipients until the complete schedule has been verified.

Version-aware destination changes

PBRS release 20250924 introduced documented email-destination update and delete operations and the option to clear existing destinations. Record that build boundary in the endpoint reference.

Preserve or replace deliberately

  • Retrieve the current destination set before changing it.
  • Choose append, update, delete or clear-and-replace intentionally.
  • Use controlled recipients for the first execution.
  • Verify both the saved destination configuration and actual downstream delivery.
  • Never log recipient credentials or sensitive message content.

Destination capability boundary

The reviewed REST contract documents creating, updating and deleting email destinations. An existing PBRS schedule may deliver to other destinations already configured in PBRS—such as disk, SharePoint, FTP or cloud storage—when the schedule is executed through the API. That does not establish REST endpoints for creating or editing those destination types.

Action Documentation position
Execute a schedule with preconfigured destinations Supported according to the schedule definition; verify each delivery
Create/update/delete an email destination Documented API operations; build-label September 2025 changes
Create/update another destination type Do not claim until Development validates an endpoint and model

Diagnose destination authentication separately

A completed PBRS API request can still fail at SharePoint, Office 365 or another downstream service because its own account, token, certificate, permission or site configuration is invalid. Record destination-specific results independently of the PBRS API status.

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.