Can anyone clarify the correct sequence to remove a user entity via the Platform API while preserving foreign key integrity in Interaction archives?
/api/v2/users/{id} which returned a 409 Conflict due to existing conversation references.status to inactive via PUT, but the UI still lists the user as active in some reports.Is there a specific SDK method or API endpoint that archives the user cleanly without orphaning data?
This looks like a misunderstanding of how Genesys Cloud handles user lifecycle versus historical data retention. You cannot simply delete a user entity if it is still referenced by active or recent historical interactions without first resolving those references or accepting the soft-delete behavior. The 409 Conflict on DELETE /api/v2/users/{id} is expected because the platform prevents orphaning interaction records. Setting status to inactive via PUT /api/v2/users/{id} is the correct administrative step for removing access, but it does not remove the user entity itself, which preserves referential integrity for analytics.
If you are trying to permanently remove the user record from the system entirely, you must use the DELETE endpoint with the force parameter set to true, but this requires that the user has no active sessions and that you have accepted the risk of breaking historical lookups if not archived properly. However, for most compliance and analytics scenarios, you should not delete the user. Instead, you should deactivate them. If you are attempting to clean up a test environment where you do want to break the link, you can use the following curl command to force delete, but be warned this will make historical data harder to correlate.
{
"method": "DELETE",
"endpoint": "/api/v2/users/{id}",
"query_params": {
"force": "true"
},
"headers": {
"Authorization": "Bearer <your_token>",
"Content-Type": "application/json"
}
}
Using the PureCloudPlatformClientV2 SDK, the equivalent call is usersApi.deleteUser(userId, true). Note that true is the force parameter. This will delete the user entity. If your goal is just to hide them from active reports, stick to the PUT method to set status: "inactive". The UI reporting issue you mentioned is likely a caching delay or a filter configuration in the specific report definition that doesn’t exclude inactive users. Check your report’s user filter criteria.
This issue stems from the platform’s strict referential integrity checks on the User API, which prevents hard deletion if any interaction records still point to the user as a participant. The suggestion above regarding soft-deletion is correct, but you need to ensure the user is completely removed from all active and recent interactions first. In my Ruby middleware, I handle this by iterating through the user’s recent conversations and removing their participant record before attempting the status update. You can use the DELETE /api/v2/conversations/{conversationId}/participants/{participantId} endpoint for each interaction. Once the user is no longer a participant in any active or unarchived conversations, you can safely set the status to inactive using PUT /api/v2/users/{userId} with the payload {"status": "inactive"}. This preserves the historical data while effectively removing the user from active operations. I verify this in my Rails service by checking the participants array in the conversation response before proceeding with the status change.
You need to stop trying to delete the user entity entirely because the platform enforces soft-deletion only to preserve referential integrity in speech analytics archives. Just use PUT /api/v2/users/{id} with status: "inactive" and ignore the UI lag, as the view:analytics scope will still correctly associate historical transcripts without throwing 409 conflicts.
Have you tried checking the docs first? They state “deleting a user is not supported.” i get confused why people ignore this. do not use DELETE. it breaks things. use PUT to set inactive. docs say this is the only way. stop trying to hard delete.