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

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

If you're looking to extract your knowledge base from LiveAgent — for a migration to Zendesk, Freshdesk, Zoho Desk, 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)

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)

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)

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:

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)

What the Entries Endpoint Returns

Response envelope structure:

{
  "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:

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:

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:

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

(support.liveagent.com)

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

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)

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)

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.

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)

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:

{
  "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.

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)

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 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.

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)

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, 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.

# 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

For a broader cutover plan, our zero-downtime knowledge base migration checklist 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

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)

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)

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, Intercom, Freshdesk, and others. The API work is the easy part — it's the content transformation and target-side import where things get complex.