> ## Documentation Index > Fetch the complete documentation index at: https://docs.yo-lead.com/llms.txt > Use this file to discover all available pages before exploring further. # Chats and tickets > Understand YoLead conversations, tickets, statuses, and repeat requests. YoLead uses `chat` for the client-channel relationship and `ticket` for each separate request inside that chat. ## Chat vs ticket | Term | Meaning | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `company channel` | A connected social or messaging account of your company, such as a WhatsApp Business account, Telegram bot, Instagram account, Facebook page, or VK group. | | `chat` | A stable link between one company channel and one client account in a specific source channel, such as WhatsApp or Telegram. For example, if John writes in WhatsApp and then in Telegram, YoLead creates two separate chats. A chat does not have a business lifecycle end and can receive multiple tickets over time. | | `ticket` | A single request or work episode inside a chat. | | `chat.lastTicket` | The last ticket in the chat. | | `ticket.previousTicket` | The previous ticket in the same chat, present when a repeat request creates a new ticket. | One chat can have multiple tickets over time. For example, the same client can contact the company today, close the dialog, and contact the company again later. That later request may reopen the previous ticket or create a new ticket, depending on the channel restore period. ## Ticket statuses | Status | Meaning | | ---------- | ------------------------------------------------------------------------------------- | | `new` | A new incoming request that has not been taken into work yet. | | `active` | The request is in work. It is usually assigned to an employee. | | `inactive` | The request is closed. YoLead sets `endedAt` when the ticket is moved to this status. | ## Chat status A `chat` also has a status. It stays in sync with the status of `chat.lastTicket`. ## Allowed status transitions | From | To | Meaning | | ---------- | ---------- | ----------------------------- | | `new` | `active` | Take a new request into work. | | `active` | `inactive` | Close the request. | | `inactive` | `active` | Reopen a closed request. | Direct `new` to `inactive` transitions are not allowed. A new request must be taken into work before it can be closed. Moving a chat back to `new` is not allowed. To transfer an active ticket to another employee, use [`PATCH /v1/tickets/{ticketId}/assignee`](/api-reference/tickets/change-ticket-assignee). ## Scenarios | Scenario | Result | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | First incoming message from a client in a channel | A new `chat` and the first `ticket` are created with ticket status `new`. | | Incoming message while the current ticket is `new` or `active` | The message is added to the current ticket. | | Incoming message after the current ticket was closed, within the restore period | The last ticket reopens automatically: its status changes from `inactive` to `active`. | | Incoming message after the current ticket was closed, after the restore period | A new ticket is created in the same chat and linked to the previous ticket with `previousTicket`. | ## Restore period The restore period controls what happens when a client sends a new message after a ticket was closed. The restore period is stored as `restorePeriodMs` and is configured in the YoLead UI in the company channel settings. If the client writes within the restore period, the message is treated as a continuation of the previous ticket and the ticket reopens. If the client writes after the restore period, the message is treated as a new request and a new ticket is created in the same chat. ## Related webhooks | Event | When it is sent | | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | [`ticket.created`](/webhooks/events#ticketcreated) | A new ticket is created, including the first ticket in a new chat or a later repeat request after the restore period. | | [`message.incoming`](/webhooks/events#messageincoming) | A client message is added to an existing ticket. | | [`ticket.status_changed`](/webhooks/events#ticketstatus_changed) | A ticket changes between `new`, `active`, and `inactive`. | | [`ticket.assignee_changed`](/webhooks/events#ticketassignee_changed) | A ticket is assigned to another employee. | ## Related REST endpoints * [`GET /v1/tickets/{ticketId}/history`](/api-reference/tickets/get-ticket-history) returns ticket metadata and message history. * [`PATCH /v1/tickets/{ticketId}/status`](/api-reference/tickets/change-ticket-status) changes the current ticket status. * [`PATCH /v1/tickets/{ticketId}/assignee`](/api-reference/tickets/change-ticket-assignee) changes the assignee of the current active ticket. Endpoint-specific request and response fields are documented in the REST API reference.