Operate an existing LiveChat-to-Supportbench case connection

Updated Wednesday, October 28, 2026 · Marc Staine

An existing compatible LiveChat connection can bring completed conversations or ticket events into Supportbench as cases, preserving the conversation for follow-up with the customer. The operational value is continuity: an agent can see what the customer already explained and take responsibility for the next step. Core preserves an inbound compatibility route for this workflow, but it does not provide the old LiveChat setup page or Agent App installation workflow. Establish what your account actually has before using this guide.

At a glance

For: support operations teams and integration owners maintaining an existing compatible LiveChat connection. Applies to: Supportbench Core.

Start here: The existing LiveChat integration configuration supplied by your integration owner, plus the resulting Supportbench cases

Identify which chat product and connection you use · Confirm the connection contract before changing it · Understand when a case is created · Know what conversation data becomes visible · Verify an existing connection end to end · Turn the transcript into an effective support handoff · Investigate delivery failures without creating duplicates

Identify which chat product and connection you use

Your situation	Correct next step
You use Supportbench’s native Chat workspace and widget	Use the Supportbench Chat operations guide and Chat widget settings. This article describes a separate external LiveChat connection.
Your organization already has a working LiveChat webhook connection	Confirm its owner, destination account, accepted event format and routing defaults, then follow the verification procedures below.
You want to install a new LiveChat connection in Core	Ask Supportbench and your integration owner to confirm a supported setup, tenant mapping, secret and payload contract first. There is no current Core LiveChat settings page to follow from the old article.
You found an old Supportbench Agent App installation tutorial	Do not assume its marketplace steps or in-LiveChat panels are available in Core. Confirm the supported product/version before planning that workflow.

A webhook is a message one application sends to another when an event occurs. Here the relevant events are a completed chat or a created ticket in the expected compatible format. A webhook destination is different from the customer’s chat widget address and from an agent’s sign-in page.

Confirm the connection contract before changing it

Existing compatibility, not a new-app installation promise

Core expects the compatible event types chat_ended and ticket_created with their expected chat/message or ticket/event data. Current LiveChat/Texts developer guidance uses newer app authorization and webhook tooling. Do not assume that a newly registered event with a similar name produces the payload this connection accepts.

The integration owner must confirm the approved HTTPS destination, account-specific mapping, secret and event format. Core supports its established LiveChat webhook routes; the tenant mapping must resolve to one active Supportbench account. There is no Core screen in this workflow that creates a new mapping or reveals a setup secret, so do not construct a guessed URL from another customer’s example.

Keep the full destination and its secret out of public articles, screenshots, ordinary chat transcripts and unredacted diagnostics. Share configuration details only through your organization’s approved integration process. Provider references checked on 28 October 2026: LiveChat app and webhook guidance and LiveChat system-activity reference.

Understand when a case is created

Incoming compatible event	Core behavior to verify
Completed chat: chat_ended	A new case is created when the existing mapping enables automatic creation. An already mapped conversation can continue through its mapped lifecycle. Do not assume every completed chat creates a new case when automatic creation is off.
Ticket created: ticket_created	Creates its case through the ticket path even when the chat automatic-creation flag is off. Test the two event types separately.
Other event type or newer incompatible envelope	It is not established as supported by this compatibility route merely because the provider can send it.
An “offline message” requirement	Confirm the actual event and payload delivered by your provider configuration. There is no separately verified Core offline-message setting to enable from this article.

The mapping supplies defaults such as division, priority and queue. A detected agent can be assigned; otherwise the configured queue is used. Review the actual resulting case and lifecycle/workflow effects instead of assuming the saved default is always the final owner.

Customer identity is resolved using the supplied email. A Contact may be created from valid email/name data, with Company association informed by the applicable domain mapping. Confirm that the person belongs to the intended customer, especially for shared domains, consultants or customers with several related companies.

Know what conversation data becomes visible

The imported transcript becomes a public initial case activity. All supplied message entries are copied into that public activity; Core does not filter internal/private message types from this compatible payload. Chat duration and tags are also carried into the supported case-processing path. Review the source payload’s content and the resulting case audience before treating the connection as approved for customer use.

Do not assume that a private note, credential or internal instruction is automatically safe because it came from a chat system. The responsible integration owner must verify which message types are supplied and what appears in the public transcript. If the payload contains information that should stay internal, stop using that configuration until its handling is understood.

A public activity and a publicly accessible case are separate concepts. Customer case access still follows the applicable Supportbench identity and visibility rules. Test both the transcript content and which customer can actually open the case.

Verify an existing connection end to end

Identify the integration owner and record the intended Supportbench account, source LiveChat workspace, event type and non-secret routing expectations. Verify that the tenant mapping is active.
Choose an approved test customer identity and a harmless test conversation. Use a recognizable subject and a unique test phrase so you can find the result without copying sensitive customer data.
Complete the chat in LiveChat through its normal workflow. Confirm the provider attempted the expected compatible chat-end event. Do not manually post guessed production payloads as a substitute for a real controlled test.
Find the resulting Supportbench case using its customer identity or unique test phrase. If automatic chat creation is disabled, compare with the intended no-new-case behavior.
Open the case and verify Company, Contact, division, final owner/queue, priority, tags, transcript order and duration. Confirm the next action has a responsible person or monitored queue.
Inspect the initial activity’s public content. Test access with the intended customer identity and a representative identity that must not see that customer’s case.
Run a separate controlled ticket-created test if that route is used. Its creation behavior is different from the chat automatic-creation flag.
Record the observed source event, destination case and outcome. Enable wider operational reliance only when the actual mapping, content and audience checks meet the intended process.

Turn the transcript into an effective support handoff

Example: a chat requires an engineering investigation

A customer reports an intermittent equipment issue in LiveChat. The compatible completed-chat event creates a Supportbench case containing the conversation. The receiving agent reads the transcript, verifies the customer and device context, records what has already been tried and assigns the next investigation step. The agent sends an appropriate customer update through the case workflow rather than asking the customer to repeat the entire conversation.

Read the imported conversation before sending a response. Identify unanswered questions and promises made during chat.
Check related open cases for the same organization or asset so two teams do not run conflicting investigations.
Confirm the case’s actual owner and the next customer update time. Being present in a queue does not establish that someone has accepted the work.
Separate the imported customer transcript from new internal notes or engineering discussion.
Use the escalation process if the issue needs another team while keeping the customer communication and ownership explicit.

Investigate delivery failures without creating duplicates

First distinguish provider delivery from Supportbench case processing. A provider event that was never sent cannot appear in the receiving case workflow. A delivered event can still be rejected for its mapping or payload. Collect non-secret event timing and identifiers, the response status and the expected case identity for the integration owner.

Symptom	Check next
No case after a completed chat	Confirm the actual event delivery, compatible payload, active mapping and chat automatic-creation setting. Search for an existing mapped case before retrying.
Tickets create cases but completed chats do not	The ticket path and chat automatic-creation flag differ. Verify the intended settings and each event type separately.
A customer appears under the wrong Company	Review supplied email identity and domain/customer mapping. Correct the relationship deliberately; do not reuse another person’s Contact.
The case went to an unexpected owner	Check detected-agent matching, configured fallback queue and subsequent workflow results.
The endpoint returns 400	The event may be invalid or unsupported. Have the integration owner inspect the compatible format and mapping; retrying the same invalid data does not repair it.
The endpoint returns 503	Processing did not complete successfully and the response allows provider retry. Check whether any destination result exists before manually replaying or creating another case.
A large event is rejected	The Core receiver limits requests to 2 MiB. Review the expected payload and the provider’s supported delivery design instead of assuming unlimited transcript size.
The old LiveChat Settings page or Agent App is missing	Those are not verified native Core setup surfaces. Use an existing confirmed mapping or request a supported integration assessment.

Provider retry behavior and destination processing are separate pieces of the connection. Do not promise exactly-once delivery from an HTTP response alone. Avoid repeated manual resubmission while the provider may already be retrying; investigate the existing event and case mapping first.

Was this article helpful?