How to Export Data from FuseDesk: API Limits, Methods & Gaps

How to Export Data from FuseDesk: API Limits, Methods & Gaps

FuseDesk has no native bulk-export button for cases, contacts, or conversation history. Its export surface is split between report CSV downloads, a JSON REST API for cases and emails, and CRM-linked contact data stored in your connected CRM — Keap (Infusionsoft), ActiveCampaign, Ontraport, or GoHighLevel. If you need a migration-ready archive, you will export from FuseDesk and from the CRM. (fusedesk.com)

API version anchor: This guide reflects the FuseDesk v1 and v2 REST APIs as documented at fusedesk.com/api/ and verified against Postman collection exports. FuseDesk does not publish a changelog with version dates; cross-reference against current documentation before executing a production export.

If you are exporting as part of a move to a new platform, see our FuseDesk to Enchant migration guide or the FuseDesk vs Freshdesk architecture comparison.

Where FuseDesk Data Actually Lives

Before extracting anything, understand the split data model. FuseDesk was purpose-built for the Keap/Infusionsoft ecosystem and later expanded to other CRMs. The architecture reflects this:

• Cases (tickets): Stored in FuseDesk.
• Case history (emails, notes, calls): Stored in FuseDesk and often pushed back to the CRM.
• Contacts (names, emails, phone numbers): Stored in your CRM, not FuseDesk.
• Tags on contacts: Stored in your CRM.
• Case tags: Stored in FuseDesk.
• Departments and reps: Stored in FuseDesk.

When you view a ticket in FuseDesk, the application renders case data alongside a real-time pull from the CRM contact record. If you only export FuseDesk data, you end up with tickets assigned to bare CRM Contact IDs (contactid: 10452) with no names, emails, or phone numbers attached. This is the single most common mistake in FuseDesk migrations — teams export cases, discover they have no contact data, and have to restart.

A complete FuseDesk data export requires two parallel extractions: one from the FuseDesk API for cases, history, and reference data, and one from your CRM for contact details and company records. (fusedesk.com)

What Data Can You Export from FuseDesk?

Method 1: Report CSV Export (Metadata Only)

FuseDesk lets you download report data as CSV from the Reports UI. Some report views also expose an API URL for programmatic access. (fusedesk.com)

The documented report catalog includes metrics like Cases Opened, Resolution Time, First Response Time, Case Load, Case Assignments, and feedback or rating reports.

What you get: Case counts, response times, rep performance metrics, and filtered case lists depending on the report type.

What you don't get: Conversation threads, attachments, contact details, or raw case history.

This is useful for pre-migration baselines — SLA metrics, volume counts, assignment distribution. Export these before starting the migration so you have frozen reference numbers for reconciliation. Do not mistake report CSVs for a data archive.

Method 2: FuseDesk REST API (Primary Extraction Path)

The API is the only programmatic way to extract case-level data from FuseDesk. There is no account-level dump or XML export. (fusedesk.com)

Authentication

You need a FuseDesk API key, which requires admin-level access to create. Keys can be scoped with specific permissions. FuseDesk recommends creating a unique API key per integration so you can revoke individual keys without breaking other apps.

Two authentication methods are supported:

HTTP Header (recommended):

curl --request GET \
  --header "X-FuseDesk-API-Key: YOUR_API_KEY" \
  https://YOURAPPNAME.fusedesk.com/api/v1/cases/

Query parameter:

curl --request GET \
  --data '{"apikey":"YOUR_API_KEY"}' \
  https://YOURAPPNAME.fusedesk.com/api/v1/cases/

Use the header method and a dedicated read-only key for export jobs. A read-only key limits blast radius if the script malfunctions — it cannot accidentally write or delete records.

Rate Limits

FuseDesk enforces hourly rate limits, not per-minute like Freshdesk or Zendesk. The API returns two headers with every response:

• X-FuseDesk-Usage-Limit — your total hourly allowance
• X-FuseDesk-Usage-Remaining — calls left in the current window

The exact cap is plan- and seat-dependent — FuseDesk documentation states that each added seat increases the allowed API call volume. (fusedesk.com) FuseDesk does not publish a public plan-to-limit table; to confirm your account's actual limit, make a single authenticated API call and read the X-FuseDesk-Usage-Limit response header directly. When you exceed the limit, you receive a 429 status code. There is no documented Retry-After header, so implement your own backoff logic based on the X-FuseDesk-Usage-Remaining count.

Extracting Cases

The case search endpoint supports filtering by status, rep, department, contact ID, case tag, and date ranges. Pagination is offset-based with a documented max of 500 records per request. (fusedesk.com)

curl --get \
  --header 'X-FuseDesk-API-Key: YOUR_API_KEY' \
  --data-urlencode 'status=all' \
  --data-urlencode 'limit=500' \
  --data-urlencode 'offset=0' \
  --data-urlencode 'orderby=date_updated' \
  https://YOURAPPNAME.fusedesk.com/api/v1/cases

Key search parameters:

Date filtering supports four formats:

• Exact date: 2025-06-01
• Before: {"before":"2025-06-01"}
• After: {"after":"2025-01-01"}
• Range: {"after":"2025-01-01","before":"2025-06-01"}

To get full case details including history:

GET /api/v1/cases/CASEID

This returns case metadata plus conversation history — emails, notes, and calls attached to that case. Each history item includes a type field (email, note, or call) with the corresponding content. One structural advantage FuseDesk has over Freshdesk or Zendesk: case history is returned inline with the case detail response, so you don't need a separate conversations endpoint. The downside is one API call per case with no way to bulk-fetch history across cases.

Extracting Email Conversations

For full email body text, the emails endpoint is critical — and has a default that silently truncates your export.

curl --get \
  --header 'X-FuseDesk-API-Key: YOUR_API_KEY' \
  --data-urlencode 'caseid=12345' \
  --data-urlencode 'bodylimit=all' \
  --data-urlencode 'limit=150' \
  https://YOURAPPNAME.fusedesk.com/api/v1/emails/

The bodylimit parameter defaults to 150 characters. If you omit bodylimit=all, you export 150-character previews — not full messages. The export will appear to succeed with no errors, return valid JSON, and still be useless for migration. This is the single most common failure in FuseDesk exports. FuseDesk warns that full-body pulls can generate substantial data volumes, so budget for storage and additional API call time. (fusedesk.com)

The emails endpoint also lets you filter by caseid or casenum and pull unassigned emails via /api/v1/emails/unassigned — useful for capturing orphaned communications that never got attached to a case.

Contacts and the CRM Dependency

This is the part teams consistently underestimate. FuseDesk's v1 Contacts API pulls from your CRM, not from FuseDesk-native records:

GET /api/v1/contacts/CONTACTID

FuseDesk also has a v2 Contacts API that returns FuseDesk-native contacts independent of the CRM. The v2 contact endpoint is documented in the FuseDesk Postman collection rather than the primary API docs page; if you need contacts that exist only in FuseDesk (e.g., chat visitors who never entered the CRM), request the Postman collection from FuseDesk support or check developer resources for the current v2 path. Do not assume v1 and v2 return equivalent data structures — v2 returns FuseDesk-internal fields that v1 omits.

For a reliable bulk customer export, pull contacts from the CRM directly and treat FuseDesk as the interaction layer. From Keap, for example:

1. Navigate to CRM > Contacts.
2. Select all contacts.
3. Choose Actions > Export.
4. Include Contact ID, First Name, Last Name, and Email.
5. Download the CSV.

Your migration script maps contactid values from FuseDesk cases to email addresses from the CRM export. When constructing tickets in your new helpdesk, you use the email address as the requester — standalone helpdesks like Freshdesk, Zendesk, and Enchant all key on email, not CRM IDs.

Reference Data: Reps, Departments, Tags

These are lightweight lookups. Pull them first — they're your mapping tables for the case export.

GET /api/v1/departments/
GET /api/v1/departments/all    # includes archived departments
GET /api/v1/reps/
GET /api/v1/casetags/

These return all records in a single request with no pagination. Use /departments/all so archived departments don't disappear from your mapping table — you need them to resolve historical ticket routing. (fusedesk.com) Omitting archived departments means older cases reference department IDs that resolve to nothing in your mapping tables.

Attachments

Attachments are the hardest part. FuseDesk has no dedicated bulk attachment download endpoint. Attachment references are embedded in case history responses.

To export attachments:

1. Parse the case history JSON for each case.
2. Identify attachment references (URLs and filenames) within the history array.
3. Write a secondary script to download the files to local storage or cloud storage.
4. Test authentication behavior before running at scale: some attachment URLs include a temporary access token in the URL itself; others require the X-FuseDesk-API-Key header. A 403 Forbidden response on a plain GET indicates the latter. Validate this on a sample of 10–20 cases with attachments before scripting bulk download logic.

HTML emails and inline images require sample-based testing before you commit to a migration timeline — the public API docs do not fully specify how inline images are represented in the export payload. Pull 20–30 real tickets that contain attachments and inline images, inspect the JSON structure, and confirm your parser handles both cases before running a full extraction. (fusedesk.com)

Method 3: Zapier (Event-Based, Not Bulk)

FuseDesk integrates with Zapier, which can trigger on events like new cases or case updates. This is useful for ongoing sync to another platform — pushing new cases to a Google Sheet, Airtable, or another helpdesk as they arrive.

Zapier will not backfill your existing case history. If you're using Zapier as a migration bridge, you still need the API for historical data. Zapier is appropriate for post-migration forward-sync, not for historical extraction.

Data Retention: Check Before You Export

This is a critical step that teams regularly skip. FuseDesk PRO and Enterprise plans can configure automatic archival, anonymization, and deletion for five data objects: Cases, Chats, Reps, Contacts, and Emails. These operations happen in that exact order — archival first, then anonymization, then deletion — and can be configured up to 84 months (7 years) after case closure. (fusedesk.com)

The defaults matter:

• Cases: Never archived, anonymized, or deleted by default. Configurable up to 84 months after closure.
• Chats: Same defaults and ceiling as cases.
• Contacts: Deletion only. Hard deleted immediately by default after the contact is deleted. PRO allows 1–7 days grace period; Enterprise allows 1–90 days.
• Emails: Hard deleted 7 days after being sent to Trash by default. PRO allows instantly to 30 days; Enterprise allows instantly to 90 days.
• CRM data: FuseDesk warns that deleted or anonymized FuseDesk data may still exist in the connected CRM. Retention must be reviewed there independently.

FuseDesk's anonymization is "best effort" for PII inside free-text content — structured fields like names and emails get scrubbed, but PII embedded in message bodies may survive. This is relevant for compliance: do not assume anonymization means full GDPR erasure of free-text content. (fusedesk.com)

Building a Complete Export Script

Here's the extraction sequence for a full-fidelity FuseDesk export. Steps are ordered to minimize wasted API calls — reference data first, then cases, then per-case enrichment.

Step 1: Pull reference data

# Departments (including archived), Reps, Case Tags
# Small payloads, no pagination needed
# Do this first — these are your foreign key lookup tables
departments = get("/api/v1/departments/all")
reps = get("/api/v1/reps/")
case_tags = get("/api/v1/casetags/")

Step 2: Catalog total case count

# Use limit=1 to get total case count before committing to full extraction
probe = get("/api/v1/cases/?status=all&limit=1&offset=0")
total_cases = probe['total']  # Use this to estimate extraction hours against your rate limit

Step 3: Paginate through all cases

all_cases = []
offset = 0
while True:
    batch = get(f"/api/v1/cases/?status=all&limit=500&offset={offset}")
    if not batch:
        break
    all_cases.extend(batch)
    offset += 500
    check_rate_limit()  # Read X-FuseDesk-Usage-Remaining header; pause if < 100

Step 4: Fetch full history for each case

for case in all_cases:
    case_detail = get(f"/api/v1/cases/{case['caseid']}")
    # case_detail includes history array: emails, notes, calls
    # Save raw JSON before any transformation — this is your audit trail
    save_raw(case_detail)
    check_rate_limit()

Step 5: Fetch full email bodies

# bodylimit=all is mandatory — default is 150 characters (silent truncation)
for case in all_cases:
    emails = get(f"/api/v1/emails/?caseid={case['caseid']}&bodylimit=all")
    save_emails(case['caseid'], emails)
    check_rate_limit()

Step 6: Enrich with CRM contact data

unique_contact_ids = set(c['contactid'] for c in all_cases if c.get('contactid'))
for cid in unique_contact_ids:
    contact = get(f"/api/v1/contacts/{cid}")  # Pulls from CRM via FuseDesk v1 API
    save_contact(contact)
    check_rate_limit()

Step 7: Pull orphaned emails

# Captures communications that never got assigned to a case
unassigned = get("/api/v1/emails/unassigned")
save_unassigned(unassigned)

Edge Cases That Break Naive Exports

Contact ID mismatches across CRMs. If you switched CRMs while staying on FuseDesk (e.g., Keap to GoHighLevel), older cases may have contactid values that reference the previous CRM. These IDs won't resolve against your current CRM's API. To detect this: query your current CRM for a sample of contactid values from old cases — if the lookup returns 404 or empty, you have an ID mismatch problem. Resolution requires either a contact ID mapping table from the CRM migration or manual case reassignment.

Anonymized cases are structurally present but data-scrubbed. Cases processed by retention anonymization rules are still visible via admin-level API keys. The case structure remains, but contactid and PII fields will be null or replaced with placeholder values. These cases will appear in your paginated case export but will be unresolvable to a real customer. Filter them by checking for null contactid before attempting CRM enrichment.

Offset pagination is not guaranteed consistent during live exports. FuseDesk uses offset-based pagination with no cursor or snapshot mechanism. If new cases are created during your export window, later pages may shift — a case near the boundary of two pages could be duplicated or skipped. For large accounts (10,000+ cases), use date-range windowing (date_opened with before/after filters) to break the extraction into fixed time windows rather than relying on raw offset continuity. (fusedesk.com)

Truncated email bodies by default. The emails endpoint returns 150-character previews unless you pass bodylimit=all. The response will be valid JSON with no error indicator. You will not know the bodies are truncated unless you check the character count of exported messages. This is the single most common silent failure in FuseDesk exports. (fusedesk.com)

HTML emails and inline images need sample testing. FuseDesk supports HTML emails and inline attachments, but the public API docs do not fully specify how inline images are represented in the export payload. Extract and manually inspect 20–30 real tickets containing HTML and attachments before committing to a migration timeline. (fusedesk.com)

Attachment URL authentication is not uniformly documented. Some attachment URLs are self-authenticating (token embedded in URL). Others return 403 Forbidden on an unauthenticated GET and require the X-FuseDesk-API-Key header. Test both patterns on a real attachment sample before writing bulk download logic.

What FuseDesk Won't Let You Export

• Chat transcripts: FuseDesk's live chat is a core feature, but there is no documented public API endpoint for extracting chat conversation history. Chats are subject to data retention settings (same archival/anonymization/deletion rules as cases) but not to the API extraction methods available for cases. If chat history is critical to your migration, contact FuseDesk support directly to request a manual data export — this is not guaranteed but is the only documented path. (fusedesk.com)
• Knowledge base content: If your KB is hosted on WordPress (as FuseDesk's setup docs recommend), export it as a separate WordPress content migration. FuseDesk's internal KB feature has no documented export endpoint. (fusedesk.com)
• Automation rules and workflows: Campaign Builder integrations, email rules, and automation recipes are not exportable via API. These must be manually recreated in your target platform.
• Report configurations: Custom reports and dashboards are not exportable.

Comparing FuseDesk Export to Other Helpdesks

Rate limits for competing platforms are sourced from their respective API documentation: Freshdesk rate limits at developers.freshdesk.com (detailed in our Freshdesk export guide), Zendesk at developer.zendesk.com, Zoho Desk at desk.zoho.com/DeskAPIDocument (detailed in our Zoho Desk export guide). FuseDesk rate limits are plan-dependent and not published in a public table; confirm your limit via the X-FuseDesk-Usage-Limit response header.

The contact data location row is architecturally significant: every other major helpdesk stores contacts natively, so single-system extraction is sufficient. FuseDesk's CRM dependency is unique and requires a two-system extraction by design.

Pre-Export Checklist

1. Check data retention settings — Settings → Privacy in FuseDesk. Confirm nothing has been anonymized or deleted. Temporarily disable auto-deletion if configured.
2. Create a dedicated read-only API key — Don't reuse a key powering a live integration. Scope it to read permissions only.
3. Read your actual rate limit — Make one authenticated API call and record the X-FuseDesk-Usage-Limit header value. Use this, not approximations, to calculate your extraction window.
4. Catalog your case count — Run GET /api/v1/cases/?status=all&limit=1&offset=0 and record the total. Divide by your hourly call limit (accounting for 2 calls per case: one for metadata, one for emails with bodylimit=all) to estimate extraction duration.
5. Identify your CRM and confirm API access — You need contact data from both systems. If your CRM changed since FuseDesk setup, verify that older contactid values still resolve.
6. Export report CSV baselines — Freeze your SLA metrics and case counts for post-migration reconciliation before making any changes.
7. Export reference data first — Departments (/departments/all to include archived), reps, case tags. These are your foreign key mapping tables.
8. Sample 20–30 cases with attachments and HTML emails — Inspect the JSON structure manually before running bulk extraction. Confirm attachment URL authentication behavior and inline image representation.
9. Plan for the CRM-side extraction — If migrating away from Keap or ActiveCampaign simultaneously, the CRM export must be coordinated with the FuseDesk extraction so contactid values are still resolvable when you run the enrichment step.

When to Script It Yourself vs. Get Help

If you have a modest dataset, only need case metadata plus email bodies, and your CRM export is already clean, an in-house script is reasonable.

Bring in a migration team when:

• 10,000+ cases with full history — at hourly rate limits, extraction is a multi-day operation requiring rate limit management, error recovery, and checkpoint-restart logic
• Chat transcript preservation — no public API path; requires direct coordination with FuseDesk support, with no guaranteed outcome
• Attachment-heavy accounts — no bulk download endpoint; each attachment URL must be parsed, authenticated, and fetched individually; authentication behavior varies
• Dual-system extraction (FuseDesk + CRM simultaneously) — two APIs with different auth models, rate limits, and data structures, plus a join step that can fail in multiple ways
• CRM was previously migrated — older cases reference contactid values from a prior CRM; resolving these requires a historical mapping table that may not exist
• Retention or anonymization may have run — determining what data is still intact requires querying and sampling before scoping the work

For destination planning, see Top FuseDesk Alternatives in 2026 or the FuseDesk to Enchant migration guide.