Summary
In the upcoming feature to control access of recordings by applying ABAC towards Custom Access Attribute in a conversation, we plan on making changes to the behavior of the PUT /api/v2/recordings/deletionprotection public API endpoint for applying/revoking delete protection for conversations.
Today, the behavior is that either all provided conversations are processed successfully or the entire request fails. Successful requests always return 204 No Content response.
With the introduction of ABAC, it will become possible that some conversations cannot be processed due to failed ABAC checks. As such, a “partial success” response will be introduced - where the status is 200, and the body contains the list of conversations that failed to be processed with the failure reason.
Note that the change where the status becomes 200 would only occur if the request is made by a user where an ABAC policy is applied. If no ABAC is involved, the existing behaviour would continue to apply where the entire request succeeds or fails, and there would be no 200 return code. That is, there is no behavioural change in the API endpoint for organizations who are not using the new feature.
Effective Date
Monday, September 21, 2026
Customer Impact
For customers using ABAC policies, this change introduces a new partial success behavior. Requests may now return 200 OK with details of any conversations that could not be processed due to ABAC restrictions. Integrations should be updated to handle and inspect this response.
There is no impact for customers not using ABAC—existing behavior (204 on success, all-or-nothing processing) remains unchanged.
Impacted Resources
PUT /api/v2/recordings/deletionprotection
Issue References
WEM-1493
Contacts
@Daniel Ho Please reply to this announcement with any questions. This helps the wider developer community benefit from the discussion. We encourage you to use this thread before contacting the designated person directly. Thank you for your understanding.