Reference · built on requestConnectorSupport & service desks

LiveChat

Chats, threads, events, customers, and agent routing from LiveChat through the Agent Chat API and webhooks.

Request accessPricing ↗

About

LiveChat is the chat product from Text. A chat is the whole conversation with a customer, threads split it by topic with one thread active at a time, and events are what happens inside a thread: messages, rich messages, files, forms, system messages, and custom events. The Agent Chat API, at version 3.6, is served as a stateless Web API at https://api.livechatinc.com/v3.6/agent/action/ and as an RTM API over WebSocket.

Through Fibric, an operator receives incoming_chat and incoming_event webhooks, reads the thread and the customer, and proposes a message, a transfer, a tag, or a thread close for your approval. Each approved call runs once under the token's account and leaves a record of what changed and how to undo it.

This is a reference listing. It documents what Fibric would read from LiveChat and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Chats and their threads through list_chats, list_threads, and get_chat, with filters remembered across pages
  • Closed threads through list_archives, one thread per row with the full chat object
  • Events in a thread: messages, rich messages, files, forms, system messages, and custom events, each with visibility agents or all
  • Customers through get_customer, and agents, groups, tags, and routing statuses through the Configuration API and list_routing_statuses
  • Webhooks such as incoming_chat, incoming_event, chat_deactivated, chat_transferred, thread_tagged, and routing_status_set, each carrying organization_id and secret_key
  • Thread tags and thread summaries, including the thread_summary_set webhook

Proposed actions

  • Target capability: propose a message through send_event, with visibility all for the customer or agents for an internal note
  • Target capability: propose a transfer to an agent or a group through transfer_chat, after checking list_agents_for_transfer
  • Target capability: propose a tag or an untag on a thread through tag_thread and untag_thread
  • Target capability: propose closing the open thread through deactivate_chat, or reopening a chat through resume_chat
  • Target capability: propose a customer property update through update_customer

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Reply to a new chat as it arrives

    On incoming_chat the operator reads the first events and the customer record and proposes a send_event message for approval.

    With First Response

  • Move a chat from a bot agent to a person

    When a bot's thread stalls, the operator proposes transfer_chat to a group whose agents show a routing status that accepts chats.

    With Bot Handoff

  • Close chats the customer has left open

    For active chats with no customer event since the last agent message, the operator proposes tag_thread and then deactivate_chat, one call per chat.

    With Backlog Sweep

  • Move a known customer to a priority group

    The operator reads get_customer for the chat's customer and proposes transfer_chat to your priority group when the record matches your list.

    With VIP Lane

Requirements

  • A LiveChat 3 license; the API answers wrong_product_version for a LiveChat 2 license
  • A Personal Access Token or OAuth app with chats--all:ro or chats--access:ro for reading and chats--all:rw or chats--access:rw for writing
  • customers:ro or customers:rw for customer reads and updates, and agents--all:ro for agent lists
  • A webhook registered through the Configuration API register_webhook method or at app level in the Developer Console
Authentication
A Personal Access Token from Settings, Authorization in the Developer Console, sent as Basic account_id:token with scopes fixed at creation, or an OAuth app when the connector acts for several agents.

Limits

  • Rate limits apply per method and are not published as numbers; excess calls return too_many_requests and unblock after a time
  • A request times out after 15 seconds
  • send_event, transfer_chat, and deactivate_chat require the requester to be on the chat's user list unless ignore_requester_presence is set
  • The Agent Chat API covers chats and customers; tickets belong to the separate HelpDesk product and its own API

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request LiveChat ↗

Questions and answers

How does the connector authenticate to LiveChat?
With a Personal Access Token or OAuth. A token is created under Settings, Authorization, Personal Access Tokens in the Developer Console and sent as Basic authentication with account_id as username and the token as password. Its scopes are fixed at creation, and every call runs as the account that created it.
What is the difference between a chat, a thread, and an event?
A chat is the whole conversation with a customer. Threads split it into topics, and only one thread is active at a time. Events are what happens inside a thread: messages, rich messages, files, forms, system messages, and custom events. Webhooks report new ones as incoming_event.
Does LiveChat publish its rate limits?
Not as numbers. The Agent Chat API states that method calls are rate limited, that excess calls return too_many_requests, and that the block lifts after some time. Requests time out at 15 seconds. The connector paces its calls and retries after a wait.
Ask about LiveChat

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with LiveChat through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy