Legacy Dev Forum Posts

 View Only

Sign Up

Conversation endTime delay?

  • 1.  Conversation endTime delay?

    Posted 06-05-2025 18:10

    GenesysCommunity | 2016-06-08 16:25:48 UTC | #1

    I've noticed that there is sometimes a delay in setting some conversation metadata values after all participants are disconnected from a conversation.

    In our application, a call is initiated with a POST to the "conversations" path, from which we get back the call id. Once the user is finished with the call, they click a button to hang up which triggers the following synchronous actions:

    • GET to "conversations/{callId}" to get the participants of the call
    • For each participant, PUT to "conversations/{callId}/participants/{participantId}" body '{"state": "DISCONNECTED"}'
    • GET to "conversations/{callId}" to find the startTime and endTime of the conversation.

    I've noticed specifically that the last step doesn't always return a value for endTime. If I make that same GET to "conversations/{callId}" a few seconds later, the endTime will be included. So it would seem that there is sometimes a delay between disconnecting each participant and the endTime being set.

    Is this the expected behavior, or is there something wrong here? Or is there something that I could be doing differently to prevent the delay?


    KevinGlinski | 2016-06-08 16:26:28 UTC | #2

    All Conversation modification requests are async, so when you request the disconnect, the api will return before the disconnect message4 makes its flow through the system. You'll want to open up a websocket to listen for conversation state changes (here is an example using status messages http://developer.mypurecloud.com/api/tutorials/presence/#javascript) and then act on that event. Our own UI will wait 15s and if it doesn't get a notification via the websocket, it will then query the conversation to check for an update in case the websocket got dropped and the client didn't know about it.


    system | 2017-08-28 19:24:34 UTC | #3


    This post was migrated from the old Developer Forum.

    ref: 30