Deprecation - ACD Chat v2.0 - Chat Widgets 1.1 & 2.0

Announcements
1

Description

Following our ACD Web Chat v2 Deprecation Announcement posted here, we are announcing deprecation for all related Chat API v2 resources and Chat Widgets versions (Version 1.1, Version 2 and Third Party widgets). This includes the use of Third-Party Chat Routing.

All existing customers are encouraged to migrate to Web Messaging Guest APIs, and/or our Messenger App which includes both a native messaging UI client and a JavaScript SDK to build a customer client.

More Web Messaging information available here, including migration guide from Web Chat to Web Messaging.

Change Category

Infrastructure
Informational
API

Change Context

We are announcing deprecation of ACD Web Chat in order to focus all our efforts and resources on building and expanding Web Messaging, which adds a modern async experience to traditional chat, and better aligned to future expansion on Messenger as a unified framework of digital apps (including Messaging, Knowledge, Co-browse, and more coming soon). This also allows us to leverage modern technology stack for APIs and JavaScript or Mobile SDKs, for improved integration and overall stability & security.

Change Impact

The following APIs are impacted by this deprecation announcement:

For CX as Code Users: The CX as Code team will be removing the genesyscloud_widget_deployment resource and data source from the CX as Code Terraform provider in mid-April. If you are using these resources you must upgrade your CX as Code provider version after mid-April and before mid-June, you will experience errors in your CI/CD pipelines and CX as Code exports with the removal of /api/v2/widgets/deployments APIs.

Date of Change

Deprecation annotation change takes effect immediately.
Removal of ACD Web Chat v2 subject to no usage : 11 June 2025

Impacted APIs

Widgets APIs:
GET /api/v2/widgets/deployments
POST /api/v2/widgets/deployments
DELETE /api/v2/widgets/deployments/{deploymentId}
GET /api/v2/widgets/deployments/{deploymentId}
PUT /api/v2/widgets/deployments/{deploymentId}

Guest Chat APIs:
POST /api/v2/webchat/guest/conversations
GET /api/v2/webchat/guest/conversations/{conversationId}/mediarequests
GET /api/v2/webchat/guest/conversations/{conversationId}/members
DELETE /api/v2/webchat/guest/conversations/{conversationId}/members/{memberId}
GET /api/v2/webchat/guest/conversations/{conversationId}/members/{memberId}
POST /api/v2/webchat/guest/conversations/{conversationId}/members/{memberId}/messages
POST /api/v2/webchat/guest/conversations/{conversationId}/members/{memberId}/typing
GET /api/v2/webchat/guest/conversations/{conversationId}/messages
GET /api/v2/webchat/guest/conversations/{conversationId}/messages/{messageId}

Agent Chat APIs:
GET /api/v2/conversations/chats/{conversationId}/messages
GET /api/v2/conversations/chats/{conversationId}/messages/{messageId}
POST /api/v2/conversations/chats/{conversationId}/communications/{communicationId}/messages
POST /api/v2/conversations/chats/{conversationId}/communications/{communicationId}/typing
GET /api/v2/conversations/chats
POST /api/v2/conversations/chats
GET /api/v2/conversations/chats/{conversationId}
PATCH /api/v2/conversations/chats/{conversationId}
GET /api/v2/conversations/chats/{conversationId}/mediarequests
POST /api/v2/conversations/chats/{conversationId}/mediarequests
DELETE /api/v2/conversations/chats/{conversationId}/mediarequests/{mediaRequestId}
GET /api/v2/conversations/chats/{conversationId}/mediarequests/{mediaRequestId}
PATCH /api/v2/conversations/chats/{conversationId}/participants/{participantId}
PATCH /api/v2/conversations/chats/{conversationId}/participants/{participantId}/attributes
PATCH /api/v2/conversations/chats/{conversationId}/participants/{participantId}/communications/{communicationId}
GET /api/v2/conversations/chats/{conversationId}/participants/{participantId}/communications/{communicationId}/wrapup
POST /api/v2/conversations/chats/{conversationId}/participants/{participantId}/communications/{communicationId}/wrapup
POST /api/v2/conversations/chats/{conversationId}/participants/{participantId}/replace
GET /api/v2/conversations/chats/{conversationId}/participants/{participantId}/wrapup
GET /api/v2/conversations/chats/{conversationId}/participants/{participantId}/wrapupcodes
PUT /api/v2/conversations/chats/{conversationId}/recordingstate

Miscellaneous Chat APIs:
POST /api/v2/conversations/chats/memberauthtoken
GET /api/v2/routing/queues/{queueId}/conversations/chats

References

[PURE-5918]

2

Very disappointed to see there will no longer be Third-Party Chat Routing for "synchronous" real-time conversations. I get that Genesys doesn't want to provide/support their own Chat Widgets - but why get rid of all of the existing work and effort of the Chat media type and API's being used by third-party tools for actual real-time, time sensitive conversations that we don't want as Web Messaging or 'asynchronous'?

3 Likes
3

I understand your frustration. I have a customer with custom chat widget deployments that will need to be rebuilt using the headless Web Messaging deployment. The good news is at least you can rebuild a custom messaging deployment to work the same way your chat one did. Including turning off your threading to make the interactions appear and function as synchronous. So far the only real pain we have felt during migrations is that the post chat survey now needs to wait 72 hours for the message to be "done", disconnected before the email survey is sent.

1 Like
4

@ananya.singh - How long will we have to migrate off the web chat platform before it no longer works?

5

Same questiion as brian (as I asked a question alike in Impact deprecation of chat for third party routing? yesterday 7 hours before this anouncement), as we have multiple customers using a third party chat integration (agent side) which will need time to change, although I expect other choices will be made there, as customers choose for 3rd party interfacing for a reason...

2 Likes
6

@brian.jones per the announcement details "Removal of ACD Web Chat v2 subject to no usage : 11 June 2025"

7

If you've built an integration to proxy 3rd party chat messages through Genesys Cloud Webchat using the Guest Chat API, then you can look to migrate to the websocket-based Web Messaging Guest API or to the webhook-based Open Messaging API. I personally prefer the Open Messaging API because then a persistent websocket per active conversation is not needed, which makes it easier to code for, in my opinion.

As for the async nature of the messaging conversation model and the 72 hour window before the conversations is officially "closed" and any configured survey to be sent, that threading timeline is configureable in Genesys Cloud Admin under the "Threading Timeline" link. You can knock that down from 72 hours to something like 5 minutes and then surveys will be sent at a more reasonable period. Unfortunately the threading timeline is set at the platform type level, so setting it to 5 minutes for Open Messaging will set it for ALL Open Messaging platforms that you integrate into Genesys Cloud.

We realize that migrations are never welcome and cause additional work for our customers and partners. Genesys really does try to maintain backward compatibility to minimize these kinds of pain points, but the time has come for Genesys Cloud Chat to be shutdown. We are hoping that our announcement now provides enough time for you to plan migration development efforts into your development workstream to get things into place before that service goes away.

8

Thanks Jim. Looks like that was just added this morning.

9

We also recognize that some customers and partners might be using 3rd party object routing. This was a mechanism that allowed for the routing of an "object" container that represented the chat, but not the chat media itself. The idea would be that a 3rd party chat could find an agent, and when the agent accepted that "object" interaction, then the 3rd party chat system could be launched so that the agent could use it to chat with the website visitor. The "chat" portion of that functionality is also going away. There are essentially two options for this at the moment:

  1. You can switch over to routing that same objects via a 3rd party email object instead. The agent experience will essentially be the same, but it likely will effect your reporting since those objects will be seen as emails instead of chats. However, if you submit those with an email subject of something like "[Chat] some_chat_subject", then you can filter out the emails that actually are chats. We realize that is not optimal, but it will work.

  2. You can install Genesys Work Automation and use task routing to route those chats as a workitem. This works quite well and has the added benefit that you can actually define a workitem schema specific for different chat types that contain their own data attributes.

I hope that offers up some ideas for migration in that specific use case.

10

Hello, I raised a case regarding the 72-hour survey issue, and I was told that reducing the time in the threading timeline doesn't work and that it's currently just an idea. Is this true?

https://genesyspartner.force.com/customercare/apex/CaseDetail?id=5004X00002111ZF

They responded to me with this:

"The 72 hour is not configurable (currently), but there are other Org that are requesting the same under Genesys Cloud Ideas Portal

You can vote and comment. as advised "Popular ideas with high vote and comment activity will be evaluated jointly by the Genesys Product Management & Engineering teams and an update will be posted. Community feedback will play a key role in which ideas are accepted by the PM team; however, not all submitted ideas will be delivered."

11

I have tested this out in our Sandbox and it does not send the survey until 72 hours after the web message ends, regardless of the threading setting.

12

Hi @mgalindo,

The threading timeline is definitely configurable: Messaging threading timeline - Genesys Cloud Resource Center

However, @Chris_Dalziel says it doesn't affect the sending of the survey, so I'll have to ping some folks about that because that doesn't seem correct to me.

13

It would appear that the survey system may not be evaluating the configured threading timeline. See the notes at the bottom of this article: Create a web survey policy - Genesys Cloud Resource Center. I don't know if that is an oversight or if there is an upcoming enhancement to address that. I'll try to research and let everyone know.

1 Like
14

@crespino & @mgalindo I have come across this before and there is a simple solution you can do today :slight_smile: as the survey Invite "Flow" does get triggered but the email survey itself gets delayed due to the 72 hour threading in teh backend.... so the solution is simple. Put an "Agentless Email" Data action with "Survey.Url" to get teh generated survey link. This way you can also use the HTML formatting of the email through the agentless email to format the survey how you want to make it more visual as well etc.

You DO need to ensure that the "complete" survey is still inplace for analytics as if you simpily "Abort Survey" it will not have th ereporting. So i recommend sending ALL completed surveys to a inbox that is not managed as if you use a fake email address SES will end up blocking your emails if you get to many bounce backs. Personally i have a survey@mycompany.com setup that goes no where. This way the agentless email has the real email address to send it it.

You do need to consider how this will work with async though as you dont want to send them all the time so some more logic in the survey flow might be worth it eg a wait block then a dataAction check on the conversationId to see if other sessions have started etc. but this logic works and then pust the control in your hands inside the survey flow. For these async reasons you need to consider your use case and the edge use cases you might have based on your environment.

I have other customers doing this in prod today.

Cheers,
Matt

1 Like
15

We are using genesys goland sdk ("github.com/mypurecloud/platform-client-sdk-go/v129/platformclientv2" ) for our conversation related ACD usecases.

We are primarily working with:

Conversations API – GetConversation(genesysConversationId)
** Under the hood, GET /api/v2/conversations/{conversationId} can retrieve any type of conversation (voice, chat, messages, email, etc.).**

Messages-based endpoints – :
PatchConversationsMessage(genesysConversationId, body)

PatchConversationsMessageParticipant(genesysConversationId, participantId, body)

GetConversationsMessageDetails(genesysMessageId, true)

Also, we are planning to use below mentioned function of Conversations API
** PostConversationParticipantReplaceAgent**
** Here Under the hood, PostConversationParticipantReplaceAgent invokes POST /api/v2/conversations/{conversationId}/participants/{participantId}/replace/agent**

Please let us know if there is any impact here or any changes we need to do here ?

16

Hello,

These endpoints are for Messaging (Web Messaging, Open Messaging, WhatsApp, ...).
PATCH /api/v2/conversations/messages/{conversationId}
PATCH /api/v2/conversations/messages/{conversationId}/participants/{participantId}
GET /api/v2/conversations/messages/{messageId}/details

They are not for ACD Chat v1/v2 and are not listed above.
So they are not impacted by ACD Chat deprecation.

Regards,

17

This topic was automatically closed 62 days after the last reply. New replies are no longer allowed.