How to Export Data from LiveChat: Methods, API Limits & Formats

How to Export Data from LiveChat: Methods, API Limits & Formats

LiveChat (by Text) has no single "Export All" button that dumps your entire account into one file. Your extraction strategy depends on your plan tier, your technical resources, and whether you need chat metadata or full message-level transcripts. The UI raw data export (Business plan and above) gives you chat-level CSV metadata — but not individual messages. Full message-level exports require the Agent Chat API, a script that handles cursor-based pagination, and a budget for per-request API billing.

This guide covers every extraction method, what each one actually returns, the API constraints that shape your export timeline, and what you cannot get out at all.

API behavior verified against LiveChat Platform documentation (platform.text.com) and LiveChat Help Center as of July 2026. Endpoint behavior, rate limits, and pricing may change — verify against official docs before starting your export.

If you're exporting as part of a migration, these destination-specific guides cover field mapping and import constraints: LiveChat to Help Scout or LiveChat to SurveySparrow.

LiveChat Data Model: What You're Actually Exporting

Before choosing a method, understand how LiveChat structures its data. The platform does not store a flat list of messages. It uses a strict hierarchy:

License → Groups → Chats → Threads → Events

• A chat is the top-level container representing an entire conversation with a customer. It has a unique chat_id.
• A thread is a session within a chat. If a customer leaves and returns later, a new thread is created under the same chat. Each thread has a thread_id.
• An event is an individual item inside a thread: a text message, a file upload, a filled form (pre/post-chat survey), a system message (e.g., "Agent transferred the chat"), or a rich message (product carousels, quick-reply buttons).

This means a single customer relationship can span multiple threads under one chat, and each thread contains the actual message text. Any export that gives you "chat data" without drilling into threads and events is giving you metadata only — not transcripts.

Key entity types for a complete export:

Method 1: Individual Transcript Emails (Any Plan)

The most basic method. Available on every plan, including Starter.

How it works: Open Archives in the LiveChat agent app, select a chat, click the three-dot menu, and choose "Send transcript." Enter an email address and the transcript is emailed as plain text.

What you get: The full message-by-message conversation for that single chat, delivered to an email inbox.

Limitations:

• One chat at a time. No bulk option.
• No structured data format — it's an email body, not JSON or CSV.
• Completely impractical for anything beyond a handful of chats.

You can also configure transcript forwarding under Settings → Chat settings → Transcript forwarding. This auto-emails transcripts to specified addresses after every chat ends going forward. It does not retroactively send historical chats.

Method 2: CSV Report Downloads (Team Plan and Above)

To download a report, go to one and click on Export CSV. Available on the Team plan ($59/agent/month) and above.

What you get: Aggregated analytics data — total chats, satisfaction ratings, response times, missed chats, tag usage, queue metrics, and campaign conversions. Each report exports as a separate CSV.

What you don't get: Individual message content. These are analytics reports, not transcript exports.

This method is useful for operational reporting but not for data migration or compliance archival.

Method 3: Raw Data Export (Business and Enterprise Plans Only)

Exporting raw data allows you to get much more data on your chats, surveys, queues, and goals than just downloading a report.

This is the most capable UI-based export, gated to the Business plan ($89/agent/month) and Enterprise.

Available raw data export types:

• Chats report — Conference ID, chat dates/times, start URL, referrer, duration, queue duration, visitor name/IP/LiveChat ID, agent details, pre-chat survey data, post-chat survey data, tags, custom variables, response times, group status at start.
• Queue abandonment — Conference ID, queue timing, visitor info, pre-chat survey data.
• Goals — Goal ID, goal name, achievement date, agent, URL, order details.

What you still don't get: Individual message bodies. The raw data export includes metadata about each chat (duration, agent, tags, survey responses) but does not include the actual messages exchanged. If you need "what did the customer say," you need the API.

All reports can be saved to a CSV file. It's also possible to schedule reports to get all your customer service data right to your email — daily, weekly, or monthly. Scheduled exports are useful for ongoing archival but not for one-time bulk extraction of historical data.

Method 4: Agent Chat API — Full Message-Level Export

This is the only method that gives you complete transcripts with every message, event, file reference, and filled form.

Authentication

Authentication uses OAuth 2.1 with Personal Access Tokens or the full OAuth authorization code flow. For a one-time data export or a backend extraction script, Personal Access Tokens (PATs) are the only practical path. OAuth requires a browser-based redirect flow, which is impossible for a headless extraction script.

To create a PAT: Developer Console → Tools → Personal Access Tokens → Create new token. Save the token value immediately — it is shown only once and cannot be retrieved again.

Required scopes for list_archives: chats--all:ro and chats--access:ro. For supplementary endpoints: customers--all:ro and agents--all:ro.

Ensure the account generating the token has global admin privileges. If a standard agent generates the token, the API will only return chats routed to that specific agent — resulting in a catastrophically incomplete export that produces no error, only silent data loss.

Authentication header format (same for both Agent Chat API and Configuration API):

Authorization: Bearer <YOUR_PAT>
Content-Type: application/json

API Base URLs

The two relevant APIs use different base paths:

• Agent Chat API: https://api.livechatinc.com/v3.5/agent/action/<method>
• Configuration API: https://api.livechatinc.com/v3.5/configuration/action/<method>

Both use POST requests with JSON bodies. Both accept the same Bearer token authentication.

Core Export Endpoint: list_archives

The primary endpoint for historical chat extraction:

curl --location --request POST 'https://api.livechatinc.com/v3.5/agent/action/list_archives' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <YOUR_PAT>' \
  --data-raw '{
    "limit": 100,
    "filters": {
      "from": "2024-01-01T00:00:00Z",
      "to": "2024-12-31T23:59:59Z"
    }
  }'

By default each list_archives response contains the payload of 10 chats. If you would like more or fewer chats to be included in each response, you can add the limit parameter. The minimum value is 1 and the maximum is 100.

Important: list_archives only returns closed/archived chats. Chats currently in an active or open state are silently excluded. Before a final data cutover, either force-close all active sessions or separately query list_chats to capture ongoing interactions.

Pagination is cursor-based. The response includes a next_page_id token — pass it as "page_id" in the next request body to advance. Continue until next_page_id is absent or null.

What list_archives Returns

Each chat object in the response includes:

• chat_id, thread_id, timestamps (ISO 8601 format)
• Full users array (customer info + agent info)
• events array with every message, system event, filled form, and file reference
• properties (routing properties, custom properties)
• tags
• Pre-chat and post-chat survey responses (as filled_form events inside the thread's events array — not as top-level metadata fields)

Parsing Event Types

When you parse the events array, you will encounter multiple type values. Your extraction script must handle each distinctly — a script that only looks for type: message will miss files, surveys, and system events:

Critical: Pre-chat survey responses — including the customer's email and phone number — appear as filled_form events at the beginning of threads, not as top-level fields on the chat object. If you're extracting customer contact info from surveys, parse the events array, not just the thread metadata.

Pagination and Concurrency

Cursor pagination requires the token from the previous response, so you cannot parallelize a single continuous time block. If you have 500,000 chats in a given year, a single-threaded sequential script will take hours and is vulnerable to network interruptions.

Recommended architecture for large-scale exports: Build a queue-based system. A master script divides your extraction window into discrete time blocks (e.g., monthly segments for 5 years = 60 blocks). Each block is pushed to a queue as a JSON object with its own from and to timestamps. Worker scripts each pull a time block, paginate through list_archives for that block until next_page_id is null, and write results to a database or JSONL file. This approach respects the cursor constraint — pagination within a block remains sequential — while allowing multiple workers to run different time blocks in parallel.

Rate Limits

LiveChat enforces rate limits at the license level, not per token:

The rate limit is 1,000 requests per 10-minute window per license — shared across all tokens and integrations on that license — with X-RateLimit-Remaining and Retry-After headers available for backoff logic.

Practical throughput math: At 100 chats per request and 1,000 requests per 10 minutes, the theoretical maximum is 100,000 chats per 10 minutes if you dedicate the entire quota. In practice, reserve headroom for production integrations and expect ~60,000–80,000 chats per 10 minutes.

HTTP error codes your script must handle:

A common failure mode: a script that catches all non-200 responses and retries aggressively will burn through rate limits on 400 and 403 errors — which will not resolve on retry and are also billed.

API Pricing

This is where LiveChat diverges from most SaaS platforms. They won't charge you for calls made from public apps, but will bill you for any calls made from private apps or Personal Access Tokens.

They charge for all requests sent to the API apart from the requests with a 500 response status. This means 400-level errors, 403 scope failures, and 429 rate limit responses are all billed — another reason to implement proper error handling rather than retry-on-any-failure logic.

Cost example: Exporting 500,000 chats at 100 per page = 5,000 list_archives requests. Adding list_customers, list_agents, list_groups, and retry requests, total volume reaches approximately 6,000–8,000 requests. At $0.27/1,000, baseline cost is $1.60–$2.16. Attachment downloads (HTTP GETs against LiveChat's CDN) are not API calls and are not billed through this mechanism, but CDN egress costs may apply depending on your infrastructure.

Supplementary Endpoints

A complete export requires hitting multiple APIs beyond list_archives. Extract agent and group metadata before processing chat archives — chat objects reference agents, groups, and customers by alphanumeric IDs, not human-readable names.

Configuration API — list_agents:

curl --request POST 'https://api.livechatinc.com/v3.5/configuration/action/list_agents' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <YOUR_PAT>' \
  --data-raw '{}'

Returns agent ID, name, email, role, and group memberships. Store as a local lookup dictionary mapping agent_id → {name, email}.

Configuration API — list_customers:

curl --request POST 'https://api.livechatinc.com/v3.5/configuration/action/list_customers' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <YOUR_PAT>' \
  --data-raw '{"limit": 100}'

Pagination for list_customers uses the same next_page_id cursor mechanism as list_archives. Pass "page_id": "<token>" in subsequent requests until next_page_id is absent. Returns customer profiles including email, name, creation date, and custom properties.

Configuration API — list_groups:

curl --request POST 'https://api.livechatinc.com/v3.5/configuration/action/list_groups' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <YOUR_PAT>' \
  --data-raw '{}'

Returns group IDs, names, and routing settings.

Store agent and group lookups locally before processing archives. This avoids repeated API calls per chat (which would multiply your request count and cost significantly).

Method 5: Marketplace Export Apps

Two third-party apps on the LiveChat Marketplace target this use case:

Chats Exporter (by Tweak Chat): Export chats in JSON format for comprehensive archiving and backup. Generate CSV files containing essential chat metadata for quick analysis. All data processing occurs locally on your computer — their servers never see or store your chat content.

Chats Transcripts Exporter: Export your chat transcripts to a CSV file, including post and pre-chat forms and custom variables.

Method 6: Webhooks for Ongoing Capture

Webhooks are not an export method for historical data — they capture conversations going forward in real time.

To register a webhook, POST to https://api.livechatinc.com/v3.5/configuration/action/register_webhook with the event type and your endpoint URL:

curl --request POST 'https://api.livechatinc.com/v3.5/configuration/action/register_webhook' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <YOUR_PAT>' \
  --data-raw '{
    "action": "chat_deactivated",
    "url": "https://your-endpoint.example.com/livechat-webhook",
    "secret_key": "your_verification_secret"
  }'

LiveChat POSTs the full chat payload (same structure as a list_archives result) to your endpoint when the chat_deactivated event fires. The secret_key field value is included in the X-LiveChat-Signature header on each webhook delivery so you can verify authenticity.

Supported events for transcript capture include: chat_deactivated (chat fully closed), incoming_chat (new chat started), and incoming_event (individual message received).

Practical use case for migrations: Register a webhook on a cutoff date to capture all new conversations going forward, while a parallel API backfill script handles all historical data. This avoids continuously polling list_archives (burning rate limits) to keep two systems in sync during a migration window.

Handling Attachments and File Binaries

Customer support interactions rely heavily on attachments — screenshots, PDF invoices, photo evidence. In LiveChat, attachments appear as events with type: file. The event payload includes a url pointing to a file hosted on LiveChat's CDN.

Extraction constraints:

• File URL expiration: Based on empirical testing, file CDN URLs in LiveChat archives remain accessible for weeks to months, but they are not guaranteed to be permanent. Download attachments during or immediately after your archive extraction — do not queue downloads as a post-processing step weeks later. LiveChat's documentation does not specify a hard expiration interval; treat all file URLs as potentially time-limited.
• No bulk download endpoint: Each file must be fetched individually via HTTP GET.
• CDN throttling: Do not download thousands of files concurrently. Throttle to 5–10 concurrent connections to avoid connection resets or firewall blocks.

Your extraction script should: parse events arrays for type: file entries, extract the url and name fields, download each binary to local storage or an S3 bucket, and update the record with the new local file path before writing to your output format.

What You Cannot Export

Some data categories have no export path at all:

• ChatBot flows and configurations — ChatBot is a separate Text product with its own API. LiveChat's API does not expose chatbot logic or conversation flows.
• Widget appearance and customization — Theme colors, CSS overrides, button positions. Must be manually recreated in any target platform.
• Routing rules and auto-assignment logic — Internal routing configuration is not exposed through public APIs.
• Agent passwords and SSO configuration — Security credentials are not exportable (by design).
• Deleted chats — Once deleted, not recoverable through the API.
• Visitor browsing history / page views — Real-time visitor monitoring data is ephemeral and not persisted in archives.

Plan-by-Plan Export Capability Matrix

The Starter plan at $19/month supports only one user, limits visitor tracking to 100, restricts chat history to 60 days, and allows just one recurring campaign. If you're on the Starter plan and need to export historical chats, the 60-day retention window is your hard ceiling — anything older is gone and unrecoverable through any export method.

Step-by-Step: Full API Export Strategy

Recommended approach for large-scale extractions:

Step 1: Generate a PAT. In the Developer Console under Tools → Personal Access Tokens, create a new token with chats--all:ro, chats--access:ro, customers--all:ro, and agents--all:ro scopes. Use a global admin account. Save the token value immediately — it is shown only once.

Step 2: Pull agent and group metadata first. Call list_agents and list_groups via the Configuration API. Store these as local lookup dictionaries mapping IDs to human-readable names. You'll need them to resolve agent and group references in every chat object.

Step 3: Partition your date range. Divide your full extraction window into discrete blocks (e.g., monthly) to enable parallel processing. Each block will have its own independent cursor-based pagination sequence.

Step 4: Paginate through list_archives. For each time block, send POST requests with limit: 100 and follow next_page_id cursors until exhausted. Write each page to disk in JSONL format (one JSON object per line) immediately — do not accumulate in memory before writing.

import requests
import json
import time
 
BASE_URL = "https://api.livechatinc.com/v3.5/agent/action/list_archives"
HEADERS = {
    "Content-Type": "application/json",
    "Authorization": "Bearer YOUR_PAT_HERE"
}
 
def export_archives(output_file, date_from, date_to):
    """
    Exports all archived chats within the given date range to a JSONL file.
    date_from, date_to: ISO 8601 strings, e.g., "2024-01-01T00:00:00Z"
    """
    page_id = None
    total = 0
 
    with open(output_file, "w", encoding="utf-8") as f:
        while True:
            payload = {
                "limit": 100,
                "filters": {"from": date_from, "to": date_to}
            }
            if page_id:
                payload["page_id"] = page_id
 
            resp = requests.post(BASE_URL, headers=HEADERS, json=payload)
 
            # Do not retry on 400 (bad request) or 403 (auth/scope error)
            if resp.status_code in (400, 403):
                print(f"Fatal error {resp.status_code}: {resp.text}")
                raise SystemExit(1)
 
            # Halt on 401 — token is invalid or expired
            if resp.status_code == 401:
                print("Authentication failure. Regenerate PAT and restart.")
                raise SystemExit(1)
 
            # Rate limit — respect Retry-After header
            if resp.status_code == 429:
                retry_after = int(resp.headers.get("Retry-After", 10))
                print(f"Rate limited. Waiting {retry_after}s...")
                time.sleep(retry_after)
                continue
 
            resp.raise_for_status()
            data = resp.json()
 
            for chat in data.get("chats", []):
                f.write(json.dumps(chat, ensure_ascii=False) + "\n")
                total += 1
 
            page_id = data.get("next_page_id")
            if not page_id:
                break
 
            # Proactive throttling before hitting the rate limit
            remaining = int(resp.headers.get("X-RateLimit-Remaining", 100))
            if remaining < 50:
                time.sleep(2)
 
    print(f"Exported {total} chats to {output_file}")

Step 5: Extract customer profiles. Call list_customers via the Configuration API using the same next_page_id cursor mechanism. Pull full customer records to get emails, names, and custom properties that may not be embedded in chat archives.

Step 6: Download file attachments. Parse events arrays for type: file entries, extract CDN URLs, and download binaries immediately. Store to local disk or S3. Update records with the new file paths before finalizing output.

Step 7: Validate. Compare your exported chat count against the total chats metric in LiveChat Reports for the same date range. Common sources of discrepancy: bot-only conversations (no human agent involved), system threads, and chats still in active/open status (excluded from list_archives).

Edge Cases That Break Exports

Deleted agents: If an agent leaves and their LiveChat profile is deleted, their alphanumeric ID remains hardcoded in historical chat archives but will not appear in list_agents responses. Your script must handle null lookups and assign orphaned chats to a placeholder "Legacy Agent" profile to prevent constraint violations in your destination system.

Bot conversations: If you use ChatBot (Text's chatbot product), bot-handled conversations appear in list_archives with the bot listed as a participant rather than an agent. Your script needs to handle cases where no human agent was involved. If migrating to a system that charges per-agent-seat for historical data, map bot interactions to a distinct non-billable user or filter them out if they hold no historical value.

Active and incomplete threads: list_archives only returns completed, closed chats. Open chats are silently excluded with no error or warning. Run a final list_chats query (which returns currently active threads) before cutover to identify what's missing.

Transferred chats: When a chat is transferred between agents, the thread contains events from both agents. The "last operator" field in raw data exports may not reflect the full handling chain. Parse the events array for system_message transfer events to reconstruct the complete routing history.

Unicode and emoji: Chat messages frequently contain emoji and non-ASCII characters. The Python code above uses ensure_ascii=False in json.dumps to preserve these correctly. If converting to CSV downstream, ensure your CSV writer is also UTF-8 aware — many default CSV libraries truncate or mangle multi-byte characters.

Pre-chat survey data location: Survey responses appear as filled_form events at the beginning of threads, not as separate metadata fields on the chat object. Customer email, phone, and any other pre-chat form fields are inside the events array. Your parsing logic must traverse events to find these values — they are not surfaced at the top level of the API response.

Data Mapping for Migrations

If your extraction feeds a platform migration, the destination system's data model dictates how you transform the LiveChat JSON.

Timestamp Preservation

LiveChat stores timestamps in ISO 8601 format or Unix epochs depending on the payload field. When pushing data into a new system, confirm that the destination API allows you to override the created_at field with the original timestamp. If it does not, every imported chat will appear as if it occurred on the day you ran the import — destroying your historical timeline and making date-range filtering in the new system meaningless.

Migrating to Ticket-Based Systems

LiveChat's real-time chat model must be transformed into a ticket model for traditional help desks. The chat → thread → event hierarchy needs flattening.

Help Scout, for example, uses a conversation and thread model but caps threads at 100 per conversation. If a LiveChat chat contains more events than this limit, you must programmatically split it into multiple conversations. See the LiveChat to Help Scout migration guide for field-level mapping details.

LiveChat's rich message types (product carousels, quick-reply buttons, custom cards) require conversion. Most destination help desks cannot import these JSON structures natively. Your script must parse them into readable plain-text or HTML blocks. Failing to do so results in raw JSON blobs appearing inline in the destination conversation history.

GDPR Data Portability and Deletion

For GDPR Article 20 compliance (right to data portability), the Agent Chat API returns JSON — a structured, machine-readable format that satisfies the portability requirement. However, there is no per-customer "download my data" endpoint. To export a single customer's data, filter list_archives using the filters.customer_id parameter:

{
  "filters": {
    "customer_id": "<customer_livechat_id>"
  }
}

Compile all threads and events returned across paginated results for that customer ID.

For GDPR data deletion (Article 17), LiveChat provides separate deletion endpoints for customer data. Export first, delete second — once a deletion request is processed, the data is unrecoverable through any API call.

When the Export Gets Complex

For large-scale exports (500K+ chats), the combination of rate limits, per-request billing, and the engineering effort to handle pagination, error recovery, attachment downloads, ID resolution, and data type transformation makes this a non-trivial project. A basic script that works for 1,000 chats will encounter memory issues, rate limit failures, null pointer exceptions on deleted agents, and encoding errors when run against a multi-gigabyte enterprise dataset.

If you're migrating to a new platform, the extraction is only half the problem. The target system's import API has its own constraints, data model differences, and rate limits. At ClonePartner, we handle the API limits, the edge cases, and the complex data mapping — ensuring your historical data moves securely, accurately, and without interrupting your business.