The failed_transaction_modification_ids field in the batch status response has been marked as deprecated and will be removed in a future version.

The response now includes reject_on_invalid and error message in the response for observability batch transaction API.

Transactions with non-unique modification IDs within a batch are marked accordingly in the validation results file, and those transactions are rejected.

reject_on_invalid configuration flag moved to request body.

Trigger the execution of set of scheduled rules for a specific date

• POST /api/rules/rerun

Each batch must contain only unique transaction modification IDs. If duplicate transaction modification IDs are detected, the entire batch will be rejected, regardless of the reject_on_invalid flag is set to either true or false.

Added conditional retention tracking fields to DataDeletionProcessDto response.

Data deletion process queries now return additional information about which data protection regime and conditional retention rules were applied, including the regime ID, conditional retention description, and the conditions that were evaluated during offboarding.

Updated validation for ConditionalRetentionPeriods in DataProtectionRegime.

Enhanced validation rules for conditional retention periods when creating or updating data protection regimes.

Added validation in the receptor for the ScreenResponseDto to ensure that entities is not null. This is not a breaking change, because sending entities as null was silently failing before, but now we've improved the endpoint so it returns a 400 with the details of the error instead of silently failing down the line.

The response now includes rule_description. The alert_count field has been removed and replaced with total_alerts_received and unique_alerts_after_deduplication in the response for obervability rule execution API.