Genesys Cloud - Developer Community!

 View Only

Sign Up

  • 1.  Clarification on Multiple Calls for a Single Participant in Get Conversation API

    Posted 03-26-2025 09:54

    Hello,

    I've reviewed the documentation and forum discussions but couldn't find a clear explanation of how a single participant can have multiple call entries in the calls array within the GET /api/v2/conversations/{conversationId} API response.

    The response schema defines participants as an array, where each participant has a calls array. Under what scenarios can a participant have multiple calls within the same conversation? Should I handle any edge cases for this in my implementation?

    Any insights or official documentation references would be greatly appreciated!

    Thanks in advance.


    #PlatformAPI

    ------------------------------
    David Micevski
    ------------------------------


  • 2.  RE: Clarification on Multiple Calls for a Single Participant in Get Conversation API

    Posted 03-26-2025 12:17

    Hi David,

    The key concept is that each entry in the calls array represents a distinct call leg or segment that the participant was involved in during the lifecycle of that specific conversation.

    A single voice conversation isn't always a simple A-to-B connection. It can involve multiple connection segments for any given participant.

    Here are the common scenarios where a participant (Agent, Customer, IVR, External Contact, etc.) can accumulate multiple call entries:

    1. Transfers (Blind/Warm/Consult):

      • Consult Transfer (Warm): An agent (Agent A) is talking to a customer. Agent A initiates a consult call to Agent B.
        • Agent A will have their initial call leg with the customer.
        • Agent A will get a second call entry representing the consult leg to Agent B.
        • When Agent A merges the call or completes the transfer, the states and end times of these legs will update accordingly. Agent B will also get their own call entry when they answer the consult.
    2. Conferencing:

      • An agent conferences in another agent, supervisor, or external number.
      • The agent initiating the conference will maintain their original call leg (e.g., to the customer) and gain a new call entry for the leg connecting to the newly added conference participant.
      • Each participant in the conference (original customer, agent, added party) will have at least one call entry representing their connection to the conference bridge.

    Handling Edge Cases in Your Implementation:

    Yes, you absolutely should design your implementation to handle the possibility of multiple calls entries per participant:

    1. Iterate: Always loop through the calls array for each participant rather than assuming there will only be one entry (participant.calls[0]).
    2. State Aggregation: Determine how you want to represent the participant's overall status if they have multiple active or recently disconnected legs (e.g., during a consult transfer, an agent is connected on two legs simultaneously). You might need custom logic based on the state and disconnectType of the different legs.
    3. Timeline Reconstruction: If you need a precise timeline of a participant's involvement, you'll need to consider the startTime and endTime of all their call legs, potentially sorting them and merging overlapping periods if required.
    4. Identify Primary vs. Secondary Legs: Depending on your use case (e.g., calculating agent talk time with the customer), you might need logic to identify the "primary" leg (e.g., the one connected to the customer) versus secondary legs (like consults). This often involves looking at the direction, disconnectType, or related participant IDs.

    In summary, multiple calls entries per participant are a standard part of how Genesys Cloud models complex voice interactions involving multiple connection segments like transfers and conferences. Your code should anticipate and correctly process this structure.

    For more information see the response section of the POST /api/v2/analytics/conversations/details/query 30 API call.
    You can read up on the Conversation detail query 38 and Conversation Detail Data Model 56 for some more detailed information on conversations.

    The overview of Conversation Detail Data Model gives the following information:

    A conversation record represents the activity within a conversation from an analytics perspective. A conversation can involve multiple participants such as the customer, and IVR, an ACD, or an agent. Each participant will be active in one or more communications or sessions that represent activity for a specific media type. Each session can be broken up further into segments that represent a particular state with a start and an end time (if the segment has ended). A session may also contain flow data and for the voice media type call quality stats ( mediaEndpointStats ). Conversations may also have surveys and evaluations associated with them. Each of these different layers of a conversations will contain dimensions that describe the conversation. Timestamps for activity are tracked for the whole conversation (conversation start and end) and individual segments



    ------------------------------
    Orhun Sahin
    Software Development Engineer
    ------------------------------



  • 3.  RE: Clarification on Multiple Calls for a Single Participant in Get Conversation API

    Posted 03-27-2025 11:47

    Hi Orhun, 

    Thank you for the clarification and resources provided.



    ------------------------------
    David Micevski
    ------------------------------