Programmatic Web Messaging Session Termination via REST API

Need some help troubleshooting the correct sequence to terminate a Web Messaging conversation from the backend. I am building a Rust service using tokio and reqwest to manage session lifecycles for high-volume chat bots. The goal is to programmatically end a session when a specific business logic timeout is reached, without waiting for the guest to disconnect.

I have tried sending a DELETE request to the conversation endpoint, but the API spec does not list a direct delete path for web messaging conversations. I understand I need to close the conversation first, but simply setting state to closed via PATCH does not immediately release the WebSocket connection on the guest side in my testing.

Here is the payload I am using for the state update:

{
 "state": "closed",
 "wrapUpCode": {
 "id": "some-wrap-up-id"
 }
}

Is there a specific flag or subsequent API call required to force the guest client to drop the connection? Or should I be using a specific close endpoint? The documentation is slightly ambiguous on the exact HTTP method for forced termination, and the available endpoints for web messaging seem limited to retrieving messages and managing deployments or tokens rather than direct conversation termination.

Make sure you utilize the conversations API endpoint rather than attempting to delete the conversation object itself, as that triggers a 405 Method Not Allowed error. You must send a request to update the conversation state. 1. Construct your payload with "state": "closed" and "wrapupCode": { "id": "your-wrapup-id" }. 2. Include the Authorization: Bearer <token> header with valid conversation:write scopes. 3. Execute the request using your reqwest client. This mirrors the HSM template approval flow where state transitions require explicit intent. If you skip the wrapup code, the system may reject the closure due to compliance requirements similar to opt-in/out validation. This approach ensures the session terminates cleanly without leaving orphaned resources in your backend service.

2 Likes