Callbacks vs Web Callbacks

[RomanSmoll]

Hello

It has been a few days I am beating my head against the wall for the following dilemma

How is it possible to distinguish webCallBacks against classic callbacks.
When i "fetch the conversation" using analyticsApi , I do not see anything that would correspond to the webcallback or identify it in a particular way..so what should I look for in this case?

Thank you and with best regards,
Roman

[Jerome.Saint-Marc]

Hello,

With Genesys Cloud, there is no notion of web callback vs classic callback.

I assume that by Web Callback, you were referring to the callback that can be created by API with POST /api/v2/conversations/callbacks, as described in Creating Scheduled Callbacks page.
And by classic callback, the callback that can be requested by a Contact Center Agent from the Genesys Desktop UI or from an Architect flow - ex: callback added to an existing conversation which includes a voice media channel/session.

POST /api/v2/conversations/callbacks will create a fresh new conversation with a "callback" media channel (customer participant - session with mediaType = callback).

POST /api/v2/conversations/{conversationId}/participants/{participantId}/callbacks allows to add a callback media channel/session (customer participant - session with mediaType = callback) to an existing/on-going conversation (by the Contact Center Agent, through an Architect flow).

What makes the difference between the 2 is only the timeline.
I mean the media type, the direction and the start time of the different sessions and segments for the different participants (i.e. customer, ivr, acd, agent).
If the conversation includes a customer participant (purpose = customer), with a session of mediaType = callback, which contains a segment (segmentType = scheduled and/or interact) which has the earliest segmentStart time (of all participants/sessions/segments), then it is a callback initiated with POST /api/v2/conversations/callbacks.

So that requires to parse and to process the different participants/sessions/segments of a conversation details.
That's what you could see in the Timeline tab of an Interaction (Performance - Interactions).

I don't know if that could fit your use case and your integration but note that it is possible to pass custom attributes (participant data/attributes) in POST /api/v2/conversations/callbacks.
You can send Key/Value pairs via the data attribute, which will be propagated to the conversation as participant data.
You could send an attribute which helps identifying Web Callbacks - ex: "MyCallbackType": "Web Callback".
Note that you can't use a participant attribute in a query filter. But you could retrieve the conversation context or conversation details of a conversation which has a callback media channel/session and check if the attribute is present.

But participant data are NOT available when you get Analytics API - Conversation Details by id with GET /api/v2/analytics/conversations/{conversationId}/details
, and they are not available making a (synchronous) query for conversation details with POST /api/v2/analytics/conversations/details/query.

In order to get access to participant data, you can use Conversations API - GET /api/v2/conversations/{conversationId}.
The conversation context (from Conversations API) is available as soon as the conversation starts, and up to 60 days after the conversation.

You can also get participant data/attributes in the Analytics Conversation Details using an Asynchronous/Job query for conversation details with POST /api/v2/analytics/conversations/details/jobs.
It is described here.
As mentioned in this page, the conversation details with participant data/attributes are served by a data lake that is updated nightly by a batch process, rather than being updated in real time.
So with the async job, the conversation details will only be available a day after the conversation occured, but will continue to be available after 60 days (I mean longer than the Conversations API Conversation context).

Regards,