---
title: "How to Export LiveAgent Knowledge Base: API Methods, Limits & Gaps"
slug: how-to-export-liveagent-knowledge-base-api-methods-limits-gaps
date: 2026-08-20
author: Nachi
categories: [Knowledge Base, Migration Guide]
excerpt: "LiveAgent has no KB export button. Full guide to extracting articles via REST API v1, handling images, rate limits, hierarchy reconstruction, and portability gaps."
tldr: "LiveAgent KB export requires the REST API v1 — no built-in export exists. Use GET /knowledgebase/entries (500 rows/page, 180 req/min) and handle images, hierarchy, and content transformation manually."
canonical: https://clonepartner.com/blog/how-to-export-liveagent-knowledge-base-api-methods-limits-gaps/
---

# How to Export LiveAgent Knowledge Base: API Methods, Limits & Gaps


# How to Export LiveAgent Knowledge Base: API Methods, Limits & Gaps

> [!NOTE]
> **TL;DR — LiveAgent Knowledge Base Export**
>
> LiveAgent has no built-in export button for knowledge base content. The admin panel's ticket export (HTML, PDF, CSV) does not cover KB articles. Your primary extraction path is the **REST API v1** endpoint `GET /knowledgebase/entries`, which returns articles, categories, forums, suggestions, and topics in a flat list — paginated at **max 500 rows per request** with offset-based paging. The API rate limit is **180 requests per minute per API key**. Inline images and file attachments are embedded in HTML content and must be downloaded separately. A **database dump** is available on request for paying customers leaving the service, but it contains raw SQL data plus an AWS S3 file structure. ([support.liveagent.com](https://support.liveagent.com/879619-How-to-export-data-from-LiveAgent))
>
> *API behaviors verified against the LiveAgent API v1 complete reference and official support documentation. API v3 KB endpoints are available within your agent panel but are not publicly documented.*

If you're looking to extract your knowledge base from LiveAgent — for a [migration to Zendesk](https://clonepartner.com/blog/blog/how-to-migrate-from-liveagent-to-zendesk-the-complete-guide/), [Freshdesk](https://clonepartner.com/blog/blog/how-to-migrate-from-liveagent-to-freshdesk-the-complete-guide/), [Zoho Desk](https://clonepartner.com/blog/blog/liveagent-to-zoho-desk-migration-the-complete-technical-guide/), or any other platform — you need to know that LiveAgent treats articles, forums, feedback boards, and suggestions as a single pool of **knowledgebase entries**. There is no separate "export articles" feature. Everything comes through the same API endpoint, and it's on you to filter, reconstruct the hierarchy, and handle the HTML content.

This guide covers every extraction method, the exact API response fields, pagination behavior, what the API drops, and the edge cases that typically break migration scripts.

## LiveAgent Knowledge Base Data Model

Before writing extraction code, understand what LiveAgent actually stores. The customer portal bundles multiple content types into a single hierarchy:

- **Categories** (`rtype: C`) — top-level and nested groupings. Categories can contain sub-categories, articles, forums, and suggestion categories.
- **Articles** (`rtype: A`) — the actual KB content, stored as UTF-8 HTML. Each article sits under a parent category.
- **Forums** (`rtype: Q`) — community discussion boards, each tied to a category.
- **Forum Topics** (`rtype: R`) — individual threads within a forum.
- **Suggestion Categories** (`rtype: G`) — containers for customer feedback and feature requests.
- **Suggestions** (`rtype: S`) — individual suggestions submitted by customers.

Every entry has a **`treepath`** field (e.g., `0|7|16`) that encodes its position in the hierarchy. The pipe-delimited IDs represent the path from root to parent. This is how you reconstruct nested structures — not through repeated API calls, but by parsing treepaths locally.

Each entry also carries:

- **`access`**: `P` (Public) or `I` (Internal/agent-only)
- **`access_inherited`**: The effective access level inherited from parent categories
- **`rstatus`**: One of `P` (Published), `D` (Draft), `N` (New), `U` (Review), `I` (Init), `C` (Completed), `L` (Planned), `S` (Started), `X` (Declined)

> [!WARNING]
> **Multi-Knowledgebase Awareness:** If you use the Multi Knowledgebase plugin, each KB has a separate `kb_id`. The default is `kb_defa`. You must enumerate all knowledge bases first via `GET /api/knowledgebase/knowledgebases` and then extract entries per KB. Content, settings, and design are unique to each instance. ([support.liveagent.com](https://support.liveagent.com/739213-Multi-Knowledgebase))

## Why the UI Export Doesn't Cover Knowledge Bases

LiveAgent's admin panel has export capabilities, but they stop at tickets and contacts.

**What you can export via UI:**

- Tickets (HTML, PDF, CSV)
- Customers and Contacts (CSV)
- Tags and Departments (CSV)

**What you cannot export via UI:**

- Knowledge Base Articles
- Category Structures
- Forums, Suggestions, and Topics
- Inline Images and Attachments
- Customer Portal Configurations

To move your KB, you're forced to use the API. Relying on screen scraping or manual copy-pasting is error-prone, strips metadata, and breaks image source URLs when the LiveAgent instance is eventually decommissioned. ([support.liveagent.com](https://support.liveagent.com/879619-How-to-export-data-from-LiveAgent))

## REST API v1: The Primary Export Path

The REST API v1 is the documented, supported way to extract KB data from LiveAgent. The key endpoint is:

```
GET https://youraccount.ladesk.com/api/knowledgebase/entries?apikey=YOUR_API_KEY
```

### Authentication and API Keys

LiveAgent uses API key authentication. Generate your key in the admin panel under **Configuration → System → API**.

**Critical: v1 and v3 use separate API keys.** If you send a v3 key to a v1 KB endpoint, LiveAgent returns `403 ApiKey not found`. Make sure you're using the correct key for the endpoint version you're calling. ([faq.liveagent.com](https://faq.liveagent.com/916372-API-v1-vs-API-v3-in-LiveAgent-Key-Differences-Authentication-and-Resolving-ApiKey-Errors))

Pass the v1 key as a query parameter:

```
?apikey=YOUR_API_V1_KEY
```

### Common HTTP Error Responses

When building extraction scripts, these are the errors you will encounter most often and what they actually mean:

| HTTP Status | Error Message (JSON body) | Cause |
|---|---|---|
| `403` | `{"message":"ApiKey not found"}` | Wrong API key, or using a v3 key against a v1 endpoint |
| `403` | `{"message":"Access denied"}` | API key exists but lacks permission for this resource |
| `429` | `{"message":"Too many requests"}` | Exceeded 180 requests/minute for this API key |
| `404` | `{"message":"Entry not found"}` | Invalid `entry_id` or entry belongs to a different `kb_id` |
| `400` | `{"message":"Invalid parameter"}` | Malformed parameter value (e.g., non-integer `limit`) |
| `200` | `{"response":{"entries": []}}` | Valid request, no matching entries (end of pagination or empty filter) |

The `200` with an empty `entries` array is especially important: it is the canonical stop signal for offset-based pagination, not an error condition.

### Listing All Knowledge Bases

If you use the Multi Knowledgebase plugin, start here:

```
GET https://youraccount.ladesk.com/api/knowledgebase/knowledgebases?apikey=YOUR_API_KEY
```

This returns each `kb_id` and its name. Default limit is 10, max 500. Loop through each `kb_id` and extract entries separately. ([support.liveagent.com](https://support.liveagent.com/840770-Complete-API-reference))

### What the Entries Endpoint Returns

**Response envelope structure:**

```json
{
  "response": {
    "entries": [
      {
        "kb_id": "kb_defa",
        "kb_entry_id": "16",
        "parent_entry_id": "7",
        "rtype": "A",
        "rstatus": "P",
        "access": "P",
        "access_inherited": "P",
        "urlcode": "how-to-reset-your-password",
        "treepath": "0|7|16",
        "rorder": "2",
        "title": "How to reset your password",
        "metadescription": "Step-by-step guide to resetting your password.",
        "keywords": "password reset account",
        "content": "<p>To reset your password, click <strong>Forgot Password</strong>...</p>",
        "conversationid": "",
        "departmentid": "",
        "views": "142",
        "votes": "5",
        "datecreated": "2024-03-15 10:22:00",
        "datechanged": "2024-07-01 08:44:00",
        "deleted": "N",
        "description": ""
      }
    ]
  }
}
```

**Important pagination and count behavior:** The response envelope does **not** include a `total`, `count`, or `next` field. There is no server-side indication of how many total records exist. The correct stop condition is receiving an empty `entries` array (`[]`) or a batch smaller than your requested `limit`. Do not rely on a partial batch as a stop condition alone — test against your specific tenant, as some edge cases return a partial last page followed by an empty page.

Each entry in the response includes **22 fields**:

| Field | Type | Notes |
|---|---|---|
| `kb_id` | text | Knowledge base identifier (e.g., `kb_defa`) |
| `kb_entry_id` | text | Unique entry ID |
| `parent_entry_id` | text | Parent category ID (`0` = root) |
| `rtype` | constlist | `H` Home, `C` Category, `A` Article, `Q` Forum, `R` Topic, `G` Suggestion cat, `S` Suggestion |
| `rstatus` | constlist | `P` Published, `D` Draft, `N` New, `U` Review, `X` Declined, etc. |
| `access` | constlist | `P` Public, `I` Internal |
| `access_inherited` | constlist | Effective access from parent |
| `urlcode` | text | URL slug for the entry |
| `treepath` | text | Pipe-delimited hierarchy path |
| `rorder` | int | Sort order within parent |
| `title` | text | Entry title |
| `metadescription` | text | HTML meta description |
| `keywords` | text | HTML meta keywords |
| `content` | text | Article body (HTML, UTF-8 encoded) |
| `conversationid` | text | Linked ticket ID (forums/suggestions) |
| `departmentid` | text | Associated department |
| `views` | int | View count |
| `votes` | int | Vote count |
| `datecreated` | datetime | Creation timestamp — format: `YYYY-MM-DD HH:MM:SS` in account timezone |
| `datechanged` | datetime | Last modification timestamp — same format and timezone as `datecreated` |
| `deleted` | constlist | `Y`/`N` — applies to suggestions and topics only; not reliably set on articles or categories |
| `description` | text | Category/forum description |

**Content encoding:** The `content` field is UTF-8 encoded HTML. It is not Base64 or HTML-entity-encoded at the transport layer — what you receive is the raw HTML string as stored in the database. Downstream systems that expect Base64 or escaped HTML will need an encoding step.

**Soft-deleted entries:** Soft-deleted suggestions and topics are returned by default in the `/entries` response with `deleted: Y`. Filter these out explicitly if you do not want to migrate deleted content. For categories and articles, the `deleted` field is unreliable — test against your tenant to verify whether soft-deleted categories appear in results.

### Pagination and Filtering

The `/knowledgebase/entries` endpoint supports offset-based pagination:

| Parameter | Default | Max | Description |
|---|---|---|---|
| `limit` | 50 | 500 | Rows per request |
| `offset` | 0 | — | Starting row number |
| `kb_id` | — | — | Filter by specific knowledge base |
| `tree_path` | — | — | Return entries under a subtree (e.g., `0\|23\|`) |
| `parent_entry_id` | — | — | Direct children of a specific category |
| `entry_id` | — | — | Single entry by ID |
| `date_changed` | — | — | Entries changed after a given date (format: `YYYY-MM-DD`, account timezone) |

**Pagination termination contract:** Send `limit=500&offset=0`. If you receive 500 entries, send `limit=500&offset=500`. Continue until the `entries` array is empty (`[]`). The safest approach is to loop until empty rather than stopping on a partial page, because the final page may coincidentally match your limit exactly in small KBs.

A basic extraction loop:

```python
import requests
import time

BASE_URL = "https://youraccount.ladesk.com/api"
API_KEY = "your_api_v1_key_here"
LIMIT = 500

def extract_all_kb_entries(kb_id="kb_defa"):
    entries = []
    offset = 0
    while True:
        resp = requests.get(
            f"{BASE_URL}/knowledgebase/entries",
            params={
                "apikey": API_KEY,
                "kb_id": kb_id,
                "limit": LIMIT,
                "offset": offset
            }
        )
        if resp.status_code == 429:
            print("Rate limit hit. Sleeping for 60 seconds...")
            time.sleep(60)
            continue
        resp.raise_for_status()
        data = resp.json()
        batch = data.get("response", {}).get("entries", [])
        if not batch:
            break  # Empty array = end of dataset
        entries.extend(batch)
        offset += LIMIT
        time.sleep(0.35)  # Stay under 180 req/min (~171 req/min effective)
    return entries
```

### Rate Limits and Throughput Planning

| Constraint | Value |
|---|---|
| API requests per minute per key | **180** |
| Knowledge base searches per minute | **100** |
| Max entries per page (`/knowledgebase/entries`) | **500** |
| Cloud KB attachment size limit | **20 MB per file** |
| Response format | JSON (default), XML (append `.xml`) |

([support.liveagent.com](https://support.liveagent.com/217359-Request-rate-limits))

**Standalone installations** (self-hosted) can override the rate limit by inserting a row into the `qu_g_settings` database table with `name="api_rate_limit"` and a custom value. Cloud-hosted accounts are locked to 180/min.

For extraction specifically, plan your throughput:

- **500 articles, no attachments:** ~2 API calls → done in seconds
- **5,000 entries + inline images:** ~10 list calls + ~5,000 file downloads ≈ 5,010 calls → ~28 minutes at 180 req/min
- **Multi-KB with 3 knowledge bases, 2,000 entries each + images:** Multiply accordingly

> [!TIP]
> You can generate **multiple API keys** in your admin panel, each with its own 180 req/min allowance. For large extractions, use separate keys for listing entries vs. downloading files to effectively double your throughput.

### The Deprecated `/knowledgebase/articles` Endpoint

LiveAgent still serves the older `GET /api/knowledgebase/articles` endpoint, but it is officially **deprecated**. It defaults to only **10 rows per page** (max 500) and LiveAgent explicitly recommends using `/knowledgebase/entries` instead — it returns all entry types, not just articles. ([support.liveagent.com](https://support.liveagent.com/840770-Complete-API-reference))

## API v3 KB Endpoints

LiveAgent's API v3 is a Swagger/OpenAPI-documented API available within your agent panel at **Configuration → System → API → APIv3 documentation**. It covers tickets, contacts, agents, and other objects in a more modern format with clearer JSON structures.

For knowledge base content specifically, v3 does expose some KB-related endpoints. However, the **v3 KB endpoints are not publicly documented** outside the agent panel. If you're building extraction scripts, start with the v1 endpoints — they're stable, fully documented in the public API reference, and return the data you need.

The v3 API uses the same **180 requests/minute rate limit** per API key, but remember: v3 uses a different API key than v1.

## MCP Knowledge Base Tools

LiveAgent documents KB tools in its MCP server, including tools to list knowledge bases, list categories, search articles, and get a KB article with attachment download URLs. This makes MCP a viable extraction surface for selective reads, AI-assisted audits, or attachment-aware article retrieval. ([support.liveagent.com](https://support.liveagent.com/578762-MCP-Tools-Reference))

The trade-off: the published MCP reference is higher-level than the REST reference. It describes the tools and permissions but does not provide the same bulk paging detail the REST reference gives you. For large, auditable exports, REST is still easier to batch deterministically.

## Database Dump (Last Resort)

LiveAgent offers a full database dump as an export path, with restrictions:

- **Eligibility:** Only available to paying customers who are leaving the service.
- **Request process:** Email `support@liveagent.com` from your account owner email address. Specify exactly what data you need.
- **Delivery:** Via SSH/SCP or Google Drive shared link.
- **Format:** Raw SQL database dump + AWS S3 file/folder structure for attachments.
- **Data freshness:** Data is stored in the SQL database for 7 days, then moved to AWS S3. The DB dump covers recent data; older files come as S3 folder exports.

> [!WARNING]
> **DB dumps contain raw, unstructured data.** LiveAgent themselves recommend using the API instead. The dump includes internal table structures, IDs, and relations that require significant reverse-engineering to make useful. Only go this route if API extraction is insufficient for your needs. ([support.liveagent.com](https://support.liveagent.com/879619-How-to-export-data-from-LiveAgent))

## What the API Does Not Return

This is where most extraction projects get derailed. The LiveAgent KB API has real gaps:

**Inline images and attachments** — Article content is returned as raw HTML. Images embedded via the WYSIWYG editor appear as `<img>` tags pointing to LiveAgent-hosted URLs (e.g., `//yourdomain.ladesk.com/scripts/file.php?view=Y&file=FILEID`). The API does **not** return a structured list of attachments per article. You must parse HTML, extract file IDs, and download each one separately via `GET /api/files/[fileid]`.

**No revision history** — The API exposes `datecreated` and `datechanged` but **no version history**. If you need article revision tracking, it's not available through any API export path. The raw database dump may contain revision tables, but this is not confirmed in public documentation.

**No author attribution** — Unlike ticket messages, KB entries don't include an author or last-editor field in the API response. The raw DB dump may link entries to agent IDs, but the `/entries` endpoint exposes no such field.

**Forum topic replies** — Forum topics (`rtype: R`) link to a `conversationid`, which is essentially a ticket. To get actual replies and discussion content, you need to fetch messages via `GET /api/conversations/[conversationid]/messages` — a separate call per topic.

**Suggestion voter details** — Suggestions expose `votes` as a count, but not who voted or individual comments. Suggestion comments are tied to a `conversationid`, requiring per-suggestion message fetching.

**Preview display settings** — LiveAgent's article editor lets you choose how an article preview is displayed (truncated text, description-based, or full text). The entries schema does not document a field for that choice. If your target platform has article cards or excerpts, you may need to infer preview behavior during mapping. ([support.liveagent.com](https://support.liveagent.com/896745-Managing-Knowledge-Base-Content))

## Handling Inline Images and Attachments

Extracting the `content` field only gives you HTML. It does not give you the actual image files or PDF attachments embedded in the article. If you migrate the HTML as-is, the `<img>` tags will still point to your LiveAgent domain. Once you decommission LiveAgent, all images in your new knowledge base break.

**File API response structure:**

Calling `GET /api/files/[fileid]?apikey=YOUR_KEY` returns a JSON object with the following fields:

```json
{
  "response": {
    "fileid": "abc123",
    "filename": "screenshot.png",
    "filesize": "48291",
    "mimetype": "image/png",
    "downloadUrl": "https://youraccount.ladesk.com/scripts/file.php?view=Y&file=abc123&apikey=YOUR_KEY"
  }
}
```

Use the `downloadUrl` field to download the binary. From LiveAgent version 4.47 onward, you must append `apikey` as a GET parameter to download the file binary. Unauthenticated requests return a login redirect, not the file.

**The extraction process:**

1. Parse the `content` HTML string for `<img>` tags and `<a>` tags pointing to LiveAgent-hosted files (typically URLs containing `/scripts/file.php` or similar patterns).
2. Extract the file IDs from those URLs.
3. Call `GET /api/files/[fileid]?apikey=YOUR_KEY` to get file metadata including the `downloadUrl`.
4. Download the binary from the `downloadUrl`.
5. Upload the binary file to your target system or cloud storage (AWS S3, GCS, etc.).
6. Rewrite the `src` and `href` attributes in the HTML to point to the new URLs.

Use an HTML parser like **BeautifulSoup** (Python) or **Cheerio** (Node.js) — don't rely on regex for HTML parsing.

> [!WARNING]
> LiveAgent protects media files behind authentication. An unauthenticated HTTP GET request to an image URL will return a login page, not the binary. You must pass your API key when downloading files programmatically.

## Reconstructing the Category Hierarchy

The `/knowledgebase/entries` endpoint returns a flat list. Rebuilding the tree structure requires parsing two fields:

- **`parent_entry_id`** — direct parent ID
- **`treepath`** — full path from root (e.g., `0|7|16` means root → entry 7 → entry 16)

```python
def build_tree(entries):
    """Group entries by parent and reconstruct hierarchy."""
    by_id = {e["kb_entry_id"]: e for e in entries}
    children = {}
    for e in entries:
        pid = e["parent_entry_id"] or "0"
        children.setdefault(pid, []).append(e)
    # Sort children by rorder within each parent
    for pid in children:
        children[pid].sort(key=lambda x: int(x.get("rorder", 0)))
    return children
```

Key things to watch:

- **Root entries** have `parent_entry_id` of `"0"` or empty string
- Sub-categories can nest arbitrarily deep — there's no enforced maximum depth
- **`rorder`** determines display order within a parent
- If your target platform enforces a strict two- or three-level hierarchy (like Zendesk's Category → Section → Article or [Desk365's](https://clonepartner.com/blog/blog/liveagent-to-desk365-knowledge-base-migration-technical-guide/) Category → Folder → Article), you'll need to flatten or pad your LiveAgent category tree during import

## Handling Internal vs. Public Content

LiveAgent supports both public-facing and internal (agent-only) articles and categories. The API returns both types. When filtering for export, check **two fields**:

- `access`: The explicitly set access level on this entry
- `access_inherited`: The effective access level based on parent category settings

**Why `access_inherited` is the correct field to use:** An article with `access: P` (Public) under a category with `access: I` (Internal) will have `access_inherited: I` — meaning it is effectively internal despite its own explicit setting. If you filter only on `access`, you will incorrectly classify internal articles as public. Always use `access_inherited` as your source of truth for visibility mapping. Most migration targets do not have inherited access semantics, so this distinction must be resolved at export time, not import time.

## Resolving Internal Links

Knowledge bases rely heavily on internal linking. In LiveAgent, article cross-references use URLs containing numeric IDs and slugs, like:

```
https://support.yourcompany.com/Knowledgebase/Article/View/123/article-slug
```

LiveAgent also generates scheme-relative URLs in some contexts (e.g., `//support.yourcompany.com/...`). Normalize all URLs to absolute `https://` before processing — scheme-relative URLs will fail in most URL parsers and downstream redirect tools.

If you migrate to a platform like Zoho Desk or Zendesk, the target URL structure changes entirely. Old links will dead-end in 404 errors.

**The link resolution process:**

1. During extraction, map every LiveAgent entry ID to its original URL using `kb_entry_id` and `urlcode`.
2. During import into the target system, capture the new article ID and new URL generated by the target platform.
3. Maintain a mapping table: `LiveAgent_ID` → `New_System_URL`.
4. Run a final pass over all imported HTML content, replacing old LiveAgent URLs with the mapped new URLs.
5. Configure 301 redirects from old LiveAgent URLs to new URLs for SEO continuity.

The `urlcode` field in the API response gives you the source-side slug. Keep that old-to-new redirect map — you'll need it for external SEO redirects as well as internal cross-link repair.

For a deeper dive into link resolution across platforms, see our [LiveAgent to Zoho Desk migration guide](https://clonepartner.com/blog/blog/liveagent-to-zoho-desk-migration-the-complete-technical-guide/).

## HTML Content and Format Conversion

LiveAgent stores article content as **UTF-8 HTML generated by a WYSIWYG editor**. Expect standard HTML tags, inline styles from the editor, `<img>` tags with LiveAgent-hosted URLs, and potentially raw HTML/CSS if the author used the HTML editing mode. LiveAgent also supports embedding videos via iframe HTML and notes that loading external iframe content may require disabling the KB CSP header setting. ([support.liveagent.com](https://support.liveagent.com/896745-Managing-Knowledge-Base-Content))

Depending on your destination, you may need format conversion:

- **HTML to HTML** — Platforms like Zendesk and Freshdesk accept raw HTML, but you must sanitize it. LiveAgent sometimes includes proprietary CSS classes or div structures that render poorly in other helpdesks. Strip custom styling and retain semantic tags (`<p>`, `<h1>`, `<ul>`, `<strong>`).
- **HTML to Markdown** — Platforms like [Intercom](https://clonepartner.com/blog/blog/liveagent-to-intercom-migration-the-technical-guide/), Notion, or headless CMS setups require Markdown. Use a conversion library like `turndown` (JavaScript) or `markdownify` (Python). Complex tables and nested lists often break during automated conversion and require manual review.
- **HTML to JSON (block format)** — Modern editors like Intercom's article editor use block-based JSON structures. Converting LiveAgent HTML to block JSON requires a custom parser to map HTML nodes to specific block types.

Many destination platforms sanitize HTML more aggressively than LiveAgent. Test a sample of your most complex articles — tables, embedded videos, custom CSS — against the target platform's editor before running a full migration.

## Delta Exports and Incremental Sync

For zero-downtime migrations, you need incremental exports. The `date_changed` parameter on `/knowledgebase/entries` is your lever for this.

```bash
# Pull only entries changed after your last sync
# Date format: YYYY-MM-DD, interpreted in the account's configured timezone
GET /api/knowledgebase/entries?apikey=API_KEY&kb_id=kb_defa&date_changed=2026-08-01&limit=500&offset=0
```

> [!WARNING]
> **Timezone caveat:** LiveAgent returns `datecreated` and `datechanged` timestamps in the account's configured timezone, not UTC. The format is `YYYY-MM-DD HH:MM:SS`. Use `GET /settings` to confirm your account timezone before running delta exports. Your `date_changed` filter parameter must also use the account timezone — passing a UTC timestamp against a UTC+2 account will silently miss entries changed in that 2-hour gap. Apply this consistently across extraction, QA, and redirect cutover. ([faq.liveagent.com](https://faq.liveagent.com/479696-Understanding-Timezone-Handling-in-LiveAgent-API-Data-Exports))

For a broader cutover plan, our [zero-downtime knowledge base migration checklist](https://clonepartner.com/blog/blog/the-ultimate-knowledge-base-migration-checklist-a-zero-downtime-plan/) covers the full process.

## Web Scraping as a Supplemental Method

If you need data the API doesn't expose — rendered HTML with exact CSS, embedded widgets, JavaScript-generated content — you can scrape the public-facing knowledge base at your customer portal URL. This is useful for:

- Capturing the exact rendered output for archival
- Extracting content from custom portal themes
- Getting the public URL structure for redirect mapping

But scraping has real limitations: it misses internal articles, draft content, metadata (views, votes, keywords), and the structural hierarchy. Treat it as a supplement to API extraction, not a replacement.

## LiveAgent KB Export: What Each Method Gets You

| Data | API v1 | DB Dump | Scraping |
|---|---|---|---|
| Article title + HTML content | ✅ | ✅ | ✅ (public only) |
| Category hierarchy | ✅ (via treepath) | ✅ (raw tables) | Partial |
| Internal/draft articles | ✅ | ✅ | ❌ |
| Article views + votes | ✅ | ✅ | ❌ |
| Meta description + keywords | ✅ | ✅ | ✅ |
| Inline images (binary) | Via file API | Via S3 dump | Via HTTP download |
| Article revision history | ❌ | Possibly (raw DB) | ❌ |
| Article author/editor | ❌ | Possibly (raw DB) | ❌ |
| Forum replies | Via conversations API | ✅ (raw) | ✅ (public only) |
| Suggestion voter details | ❌ | Possibly (raw DB) | ❌ |
| Portal theme/CSS | ❌ | ❌ | ✅ |
| Soft-deleted suggestions/topics | ✅ (`deleted: Y`) | ✅ | ❌ |
| Timestamp format | `YYYY-MM-DD HH:MM:SS` (account TZ) | Raw DB | N/A |

## Common Pitfalls in LiveAgent KB Extraction

**Forgetting multi-KB.** If you've activated the Multi Knowledgebase plugin, entries without a `kb_id` filter return only the default KB. Always enumerate knowledge bases first.

**Confusing entry types.** The entries endpoint returns articles, categories, forums, suggestions, and topics in a single stream. Filter on `rtype` to isolate what you need.

**Ignoring `access_inherited`.** An article can show `access: P` but be effectively internal because its parent category is internal. Always use `access_inherited` for visibility decisions, not `access`.

**Misreading the pagination stop condition.** The response contains no `total` or `count` field. The stop condition is an empty `entries` array, not a partial batch. Loop until empty, not until `len(batch) < LIMIT`.

**Broken image URLs after migration.** Inline images use LiveAgent-hosted URLs. If you don't download and re-host these files, your migrated articles will have broken images the moment you decommission your LiveAgent account.

**Treating soft-deleted entries as excluded.** Soft-deleted suggestions and topics (`deleted: Y`) are returned by default. Filter them explicitly if you don't want them in your migration.

**Using the deprecated `/articles` endpoint.** It still works but defaults to 10 rows per page, returns only `rtype: A` entries, and may be removed without notice. Use `/entries` instead.

**Mixing v1 and v3 API keys.** The two API versions use separate keys. Using the wrong key produces `{"message":"ApiKey not found"}` — a cryptic 403 that wastes debugging time. ([faq.liveagent.com](https://faq.liveagent.com/916372-API-v1-vs-API-v3-in-LiveAgent-Key-Differences-Authentication-and-Resolving-ApiKey-Errors))

**Ignoring timezone on `date_changed`.** The filter parameter is interpreted in the account timezone, not UTC. A UTC timestamp against a non-UTC account silently excludes entries within the timezone offset window.

**Deletion field inconsistency.** The deprecated `/articles` endpoint documents `deleted` as an article field, while the newer `/entries` reference says `deleted` applies to suggestions and topics only. Test against your tenant rather than trusting the field description blindly. ([support.liveagent.com](https://support.liveagent.com/840770-Complete-API-reference))

**Skipping URL scheme normalization.** LiveAgent generates scheme-relative URLs (e.g., `//support.example.com/...`) in some article content contexts. These will silently fail in most URL parsers. Normalize to absolute `https://` before processing.

## Production Export Workflow

1. **Enumerate knowledge bases.** Pull `/knowledgebase/knowledgebases` and create one export job per `kb_id`.
2. **Extract all entries.** Page through `/knowledgebase/entries` at `limit=500`, store raw payloads before transforming. Stop when `entries` array is empty.
3. **Filter by entry type.** Separate articles (`rtype: A`), categories (`rtype: C`), forums (`rtype: Q`), topics (`rtype: R`), and suggestions (`rtype: S`/`G`) so you can map each type to your destination.
4. **Filter soft-deleted entries.** Remove entries where `deleted: Y` unless you need them.
5. **Reconstruct the hierarchy.** Parse `treepath` and `parent_entry_id` to rebuild nested category structures. Sort by `rorder`.
6. **Download inline images and attachments.** Parse HTML for `<img>` and `<a>` tags, call the file API for `downloadUrl`, download binaries, and re-map URLs.
7. **Transform content.** Convert HTML to your target format, sanitize proprietary styling, normalize scheme-relative URLs, and map visibility (`access_inherited`) and status fields.
8. **Run a final delta pass.** Use `date_changed` for a last sync before cutover, using the account timezone consistently.
9. **Validate and build redirects.** Compare exported counts by `rtype`, verify access visibility using `access_inherited`, and build an old-to-new URL redirect map from `urlcode` values.

## When to Invest in an Extraction Pipeline

LiveAgent's KB extraction is technically straightforward — one main endpoint, predictable pagination with a clear empty-array stop condition, a flat list that's easy to reconstruct into a hierarchy. The complexity is in the downstream work: parsing HTML content, downloading and re-hosting images, mapping content types to your target platform's data model, resolving internal links, normalizing timestamps and timezones, and handling content types (forums, suggestions) that don't have a 1:1 equivalent in most other tools.

If your KB is 50 articles with minimal images, a script and a QA checklist may be enough. If you have multiple portals, internal-only content, embedded media, or you need a zero-downtime cutover, the export step becomes an engineering project.

At ClonePartner, we've built extraction pipelines for LiveAgent knowledge bases as part of migrations to [Desk365](https://clonepartner.com/blog/blog/liveagent-to-desk365-knowledge-base-migration-technical-guide/), [Intercom](https://clonepartner.com/blog/blog/liveagent-to-intercom-migration-the-technical-guide/), [Freshdesk](https://clonepartner.com/blog/blog/how-to-migrate-from-liveagent-to-freshdesk-the-complete-guide/), and others. The API work is the easy part — it's the content transformation and target-side import where things get complex.

> Need to extract your LiveAgent knowledge base for a migration? We handle the API limits, attachment extraction, HTML sanitization, hierarchy mapping, and internal link resolution. Book a 30-minute call and we'll map out the fastest path from LiveAgent to your target platform.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### Does LiveAgent have a knowledge base export feature?

No. LiveAgent has no built-in KB export button. The admin panel's export options cover tickets (HTML, PDF, CSV) but not knowledge base articles. You must use the REST API v1 GET /knowledgebase/entries endpoint or request a database dump from LiveAgent support.

### What is the LiveAgent API rate limit for KB export?

LiveAgent's API rate limit is 180 requests per minute per API key for cloud accounts. Knowledge base searches are separately limited to 100 per minute. Standalone (self-hosted) installations can override this limit via a database setting. Each API key has its own independent counter.

### How do I export LiveAgent KB articles with images?

The API returns article content as HTML with inline image URLs pointing to LiveAgent servers. You must parse the HTML for <img> tags, extract file IDs, download each file via GET /api/files/[fileid] with your API key, and re-map URLs in your content to point to the new hosting location.

### Can I do incremental LiveAgent knowledge base exports?

Yes. GET /api/knowledgebase/entries supports a date_changed parameter, but LiveAgent returns timestamps in the account's configured timezone, not UTC. Use the same timezone consistently for cutoff logic and QA.

### What data is missing from LiveAgent's KB API export?

The API does not return article revision history, author/editor attribution, individual suggestion voter details, or a structured list of file attachments per article. Forum replies and suggestion comments require separate API calls via the conversations endpoint.