I am tasked with migrating our custom python scripts from PureConnect ICWS to the Genesys Cloud Platform API.
In ICWS, I used to hit /icws/{sessionId}/interactions to get the live call state. What is the exact GC equivalent? I can’t find a direct mapping in the documentation. Sorry for the basic question!
Stop looking for direct equivalents. It is a completely different architecture.
PureConnect’s ICWS was heavily session-based and tied to the user’s connection state. Genesys Cloud is a RESTful microservices architecture. The endpoint you need is GET /api/v2/conversations/{conversationId}. If you need a firehose of real-time state changes, you must abandon polling and use WebSockets (v2.users.{id}.conversations).
Is there a similar mapping for extracting schedule shifts?
In ICWS, we had an endpoint that pulled the agent’s published schedule for the week so we could display it on our internal intranet. Finding the exact WFM endpoint in GC that matches that payload structure has been frustrating.
While you are migrating the endpoints, be careful with email interactions.
In ICWS, retrieving an email interaction usually gave you the parsed text. In GC, the /api/v2/conversations/emails/{conversationId}/messages/{messageId} endpoint will return the raw HTML body. If your middleware isn’t prepared to sanitize or parse the HTML, your downstream applications will break.
To get the SIP Call-ID in Genesys Cloud, you must query GET /api/v2/conversations/{conversationId}/details.
You cannot use the standard conversation endpoint. You must parse the participants array, locate the specific session, and extract the sipCallId attribute.
// Example extraction path
response.participants[0].sessions[0].sipCallId
Do not rely on this for internal WebRTC calls, as the SIP signaling path is completely different.
Does this fundamental difference in API architecture require us to rewrite our entire middleware integration layer?
If the paradigms between ICWS and the GC Platform API are this divergent, I need to allocate significantly more budget to our development team. I was led to believe this would be a simple endpoint swap.
Yes, you will likely need to rewrite most of the logic.
Think of ICWS like a local librarian-you have to walk in (establish a session), ask for a specific book, and keep your library card active.
The Genesys Cloud API is like an internet search engine. It is stateless. Every request is completely independent, and you use an OAuth token instead of a session cookie. It is much more powerful, but requires a totally different mindset to build!
If you are migrating SIP integrations (like call recorders or SBC analytics) that rely on the API, note that GC abstracts the telephony layer heavily.
In PureConnect, it was very easy to query the API for the underlying SIP Call-ID to trace a call through the network. Genesys Cloud hides this to simplify the conversation model. If your script relies on the Call-ID header, you have to dig deep into the participant data.