"1. Closing of the chat from the agent side with wrap-up codes"
When a participant (e.g. the workflow, the queue, an agent, ...) disconnects from the chat, a member-change event with $.eventBody.member.state = "DISCONNECTED" is raised/sent over the Guest Chat WebSocket.
The member-change event does not contain the role of the participant (if the participant is an agent or someone/something else).
It means that when a participant joins (member-join event sent over the WebSocket), you have to leverage the GET /api/v2/webchat/guest/conversations/{conversationId}/members/{memberId} request in Guest Chat API to retrieve details about the member/participant and know if he is an agent or not, or the GET /api/v2/webchat/guest/conversations/{conversationId}/members request to retrieve details about all participants.
The Wrap-Up code selected by the agent is not propagated over Guest Chat API/WebSocket.
"2. Passing of parameters for prelogin & post login status and displaying to agent"
I am not totally sure I understand what you mean.
But passing parameters (participant data - key/value pairs) is only possible when creating a new chat with POST /api/v2/webchat/guest/conversations.
You just need to define/add them under the customFields structure.
These data are then propagated to the conversation context as participant data ("context." prefix added to the custom field attribute name).
See this blog article on how to leverage this data in an Architect flow, a Script, in Interaction Details tab.
Update of parameters (update of participant data) after the creation of the chat is not supported over the Guest Chat API.
Messages from Genesys Cloud (Workflow, agent) to the Customer are carried over the Guest Chat WebSocket.
On each message from an agent, you will get a "message" event (metadata.type = "message") on the WebSocket.
So if you are properly maintaining the websocket connected, you should catch them on the WebSocket.
See here for info on the message event.