This post covers it pretty well. The short answer is that the ID you're looking for is never called that where you get it.
The ideas site uses the same login you use to submit/view Care tickets. Not everyone will have that. If you do have one of those accounts and it's not working for the ideas site, I believe Care can help with that.
Interesting... so, from the notification, I JSON-decoded the data and eventually narrowed it down to I think eventBody.participants[the one with purpose=customer].peer. This mysterious "peer" field is the only ID in the entire gargantuan object hierarchy that it would kinda-accept. However, with every request I try (not just the one with purpose=customer) I'm getting "Bad request: Messages may only be sent for connected communications" (or sometimes it'll say "non-external" instead of "connected"). So... yeah, back to the infinite loop of trial/error/Duck/Duck/Go 
But let me ask you this... is there a place with complete documentation/explanation of the wildly complex objects we get back from Genesys? I mean... okay, if they have a thing called a communication ID, but they call it a session ID when it's a part of ISomeInterfaceA but a peer when it's a part of ISomeotherInterfaceB, and all the docs do for the description is repeat the name they gave it, "communicationId"... clearly, somebody somewhere knows more about what all these things represent than its name. I know the guys who built it like OOP, as a lot of the docs for return values just list an interface name. But just mentioning the return type is utterly useless unless you happen to have a manual documenting all the different interfaces. I forget what the one for this POST call was, ISomethingOrOtherLolIdk but you get the idea. If I go to the docs and all they have for the return type is "IFoo", then I can look up what IFoo's fields are; if a parameter is an IBar, I should be able to look up IBar and find out what they need/want there. At this point... what's the point of a communication ID? It's a chat, the chat is still in progress (still "connected" by the standard definition of the word), so why would it want some other ID? It would be like me writing a function and here are my docs:
void sendChat(string foo, string bar, string baz);
Parameters:
How the heck could you be expected to understand what "foo", "bar", and "baz" mean when all you have to go on is the data type? I bet I'm missing some kind of "extended" documentation someplace, that explains some of the more cryptic, mysterious aspects of Genesys stuff... or is that wishful thinking?
That probably means you're not choosing the right participant or segment/session. It needs to be "your" session, so the participant has to be the user for which the auth token was issued. There can be more than one session per participant; the one you want should be the one that has a start date and no end date.
The schema itself is always documented in API Explorer. That's not to say that will always answer all your questions, but that's officially the complete schema definition. You can find additional documentation for specific models and endpoints throughout the site, categorized by functional area. For example:
The specific documentation you're asking for in this case to understand the communication ID is what's missing. There's no way to know that from what's in API Explorer alone.
One good approach to replicating functionality from the Genesys Cloud UI is to inspect the network console in your browser when you do the thing you're trying to replicate. That will show you the API endpoints and exact payloads being sent. For example, look at the request used when sending a message and what IDs it's using. Then fetch that conversation using your API requests and see what piece of the conversation it got that ID from.
I didn't see any end dates in the messages, but I'll just try all the participants and see which one sticks. I don't know anything about an auth token tho... I mean when I logged into my app, there's the usual Genesys access token... is that it? In that case it would be purpose=agent, not customer...?
Yeah, what they call the "schema" is just the object's structure - and I can get that from the browser's developer tools. I guess it's nice that they gave us a way to confirm that the structure we get from Genesys matches the expected structure or something... but structure !== meaning, and even in the examples they don't mention things (I always laugh when I see code in their examples like var communicationId = "communicationId_example"; // communicationId - yes, it's called a communication ID, and.......? it was definitely the meaning, not the structure, that I was more interested in getting at. Pity that's missing from the docs. But I'll definitely check out those "data model" links - I bet those will help in understanding the design of things more clearly.
Yeah, that's usually my last resort (remember a few months ago I stumbled on an undocumented API and posted about it? Yeah... playing hacker is fun ). But thanks for the reminder. Actually, I think that'll help with things like ending and wrapping up a chat.
yes, yes
FWIW all of the sdk examples are generated based on the schema; a person didn't write that. The pages outside of API Explorer are what humans contribute.
Okay, glad to hear that! No human in their right mind would call that a usable example. Anyway, thank you for the tips, and looking forward to getting this figured out. Maybe when it's all done, I'll post a _real_example to help others who get stuck in the same mess.
And thanks again - this is two days now you've answered my dumb questions. 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.