Hey again,
This is related to a post I made earlier in the SDK section... might actually belong in the Platform section, sorry if this is a double-post... I'm trying to change who I'm talking to in a warm transfer. Unfortunately, and I hate to say it cuz I know I've been saying it a lot lately, the docs just... don't say much. I've tried numerous variations on conversation ID, participant ID, and the "body" parameter of conversations.postConversationsCallParticipantConsult... (currently getting "A connected object participant is required." even though I've passed a participant ID...). But very soon I think I will have reached the limit of what can be done by random experimentation. trial'n'erroring and "throwing stuff against the wall to see what sticks". :aughing: Is there any additional inforamtion available on how exactly to accomplish this? Maybe something tutorial-y in the "embedded framework" thing?
I assume you've seen the Consult Transfer section on the Transfers page? I believe the participant ID should be your participant to initiate and update with whom you're speaking, and the participant in context for the DELETE/PATCH to end a participant. Which part of that are you stuck on?
Yes, I had seen that - in fact that page helped me get most of my transfer-related functionality done. But the trouble with that page is not what it says, but what it doesn't:
- For one thing, instead of "address" it had "userId" - leading me to believe one was required (which makes no sense on external/outbound calls).
- It also gives examples of "DESTINATION" and "BOTH"; I had to go DuckDuckGo hunting to find "OBJECT" (and never would have guess OBJECT in a trillion years, lol).
- And specific to warm transfers, what I was missing was which participant ID. Mine? The caller's? The person I was transferring to? It didn't say.
Anyway, thankfully the issue is resolved. I don't know if the lack of information is a security measure or what, but unfortunately my experience with these docs has been one of trial and error and guesswork and web searches. I don't mean to complain, and I guess the things that keep getting me stuck are common knowledge to people in the telephony biz... but hey, thank you for trying to point me in the right direction. I really appreciate all your help (and your patience 
).
Hello,
Just a clarification regarding the destination structure and the address/userId/queueId in POST /api/v2/conversations/calls/{conversationId}/participants/{participantId}/consult when initiating the consult.
This relates to the possible destination types for a transfer/consult.
If you transfer/consult to a Queue, you would have to send "queueId" with the id of the Queue.
If you transfer/consult to a Genesys Cloud user, you would have to send "userId" with the id of the User.
If you transfer/consult to a number (phone number/DNIS), you would have to send "address" with the destination number.
Once the consultation call has been created, you can use PATCH /api/v2/conversations/calls/{conversationId}/participants/{participantId}/consult to have the agent talk to the customer/caller (and put the consultation party on hold), or to the consultation party (and put the customer on hold) or to both.
DESTINATION means the agent wants to talk with the consultation participant (destination of the consult call).
OBJECT means the agent wants to talk to the caller
BOTH is essentially a sort of conference - Caller, Agent and Consult participant can talk together.
Regarding the participantId to use in POST /api/v2/conversations/calls/{conversationId}/participants/{participantId}/consult and in PATCH /api/v2/conversations/calls/{conversationId}/participants/{participantId}/consult, it is in fact the participantId of the other active user.
I mean - let's say I have a call from Customer (Caller) to Agent1.
And Agent1 wants to do a consultation call with Agent2.
When Agent1 issues the POST and PATCH requests, as that's an inbound call from a customer, he will have to use the participantId corresponding to the customer (id of the participant with purpose=customer in conversation context with GET /api/v2/conversations/{conversationId} and in conversation details with GET /api/v2/analytics/conversations/{conversationId}/details.
Genesys Cloud knows that Agent1 is the one triggering this request through the OAuth bearer/access token used when sending this Platform API request (access token obtained via an OAuth grant flow tied to a user context - like Implicit Grant, Authorization Code grant or SAML).
Regards,
Wow, thank you so much! Just reading your explanation, right away I see a few things I will need to change in my code. Where'd you get all this great info? 
Reading the different docs on Dev Center and Resource Center, checking past post on the dev forum, a lot of practice and filling gaps doing tests on the Genesys Cloud Web Desktop (checking what it sends via browser developer tools - Network traces). 
I almost always do that with any systems (not just Genesys) as it sometimes provides additional context (to understand when an API request can be sent - and what other requests happened before). I am an old fashion guy.
As an additional note, as you mentioned Embeddable Framework.
If you are using the Genesys Cloud Embeddable Framework, you can in fact manage the transfer and consult via embeddable frameworks actions. I mean script/javascript to invoke instead of having to use Platform API. Platform API will work as well. Just saying actions can be more straightforward.
In case of requesting transfer or consult, that would leverage the updateState action.
I must say I haven't practiced that one (or don't remember...) but I know it exists.
Regards,
Yeah, I wasn't using it, more just wondering if it might contain some info that seemed to be missing. And yes, I've had to resort to trying to "hack" my way to answers by viewing the Network tab as well. I normally don't have to do that for things I'm building, but this is our first serious integration project, so like I said maybe it's a perspective thing. What looks to me like missing docs might be that I haven't read some obscure RFC establishing monitoring the Network tab as a "best practice" or something. Maybe that's how everyone else is doing it, and I just need to think more like a hacker lol. Anyway, like I said, thank you very much for all the great tips.
It is not that it is a hack or a best practice.
I just consider that Genesys Cloud Web Desktop will always be up to date, in terms of what API endpoint should be used and what content/parameters should be used in a specific flow. Doc can have a delay to be updated, doc may use some terms I may not be familiar with (talking about any docs here - in general), ...
So when I have a doubt and doc is not enough to understand something, I try with Genesys Cloud Desktop in case it can provide me with the answer. It is faster to get a confirmation - and I am rather an impatient person
Aren't we all