---
title: "How to Export Data from Desk365: Methods, API Limits & Portability"
slug: how-to-export-data-from-desk365-methods-api-limits-portability
date: 2026-07-28
author: Rishabh
excerpt: "Export data from Desk365 via native CSV or REST API v3. Covers every exportable object, plan-specific rate limits, attachments, and what can't be exported."
tldr: "Desk365 CSV export covers ticket metadata only. Full conversations, attachments, and KB articles require the REST API v3 — automations, SLAs, and roles can't be exported at all."
canonical: https://clonepartner.com/blog/how-to-export-data-from-desk365-methods-api-limits-portability/
---

# How to Export Data from Desk365: Methods, API Limits & Portability


## What Data Can You Export from Desk365?

Desk365 is a cloud-based helpdesk built for the Microsoft 365 ecosystem. Its data model centers on **Tickets**, **Contacts**, **Companies**, **Time Entries**, **Knowledge Base Articles**, **Surveys**, and **Contracts**. The exportability of each object depends on whether you use the native UI export or the REST API.

<cite index="38-1">The Exports tab in the Settings > Admin section lets you track and manage all export activity related to tickets, contacts, and companies across your helpdesk.</cite>

| Object | Native UI Export | API Export (v3) | Export Format | Known Limitations / Gaps |
|---|---|---|---|---|
| **Tickets** | Yes | Yes (`GET /v3/tickets`) | CSV / JSON | <cite index="13-19,13-20">By default, the "Get all tickets" operation does not include the ticket description. You must set the "Include Description" parameter to "Yes".</cite> UI export excludes conversation threads, replies, and notes. |
| **Archived Tickets** | Yes (separate view) | Yes (same tickets endpoint) | CSV / JSON | UI requires the Archived Tickets view separately — the "All Tickets" export does not include archived tickets. The API's tickets endpoint includes archived records without needing a separate call. |
| **Conversations (Replies, Notes)** | No | Yes (`GET /v3/tickets/{id}/conversations`) | JSON | Must be fetched per-ticket. Includes agent replies, contact replies, and private/public notes with HTML body. Does **not** include the original ticket description — you must fetch that from the ticket endpoint with `include_description=1`. |
| **Contacts** | Yes | Yes (`GET /v3/contacts`) | CSV / JSON | <cite index="34-1">In contact exports, Desk365 includes both the primary department and any secondary departments the contact belongs to.</cite> |
| **Companies** | Yes | Yes (`GET /v3/companies`) | CSV / JSON | <cite index="2-6">In company exports, you will see a list of all the departments that have been created for each company.</cite> |
| **Time Entries** | Yes | Yes (`GET /v3/time_entries`) | CSV / JSON | <cite index="1-4">When customizing the export, you can select ticket fields, custom fields, and contact fields, as well as time entry fields like time spent, billable hours, etc.</cite> |
| **Knowledge Base Articles** | No | Yes (`GET /v3/kb/articles`) | JSON | Articles returned with HTML and plain text content, view/like counts, and status (draft/published). No native CSV export. |
| **KB Categories & Folders** | No | Yes (`GET /v3/kb/categories`, `/v3/kb/folders`) | JSON | Includes visibility settings, company-level access controls, and parent category mapping. |
| **Surveys** | No | Yes (`GET /v3/surveys`, `/v3/surveys/ratings`) | JSON | Survey ratings can also be included inline with ticket responses via `include_survey_details=1`. |
| **Contracts** | No | Yes (`GET /v3/contracts`) | JSON | API-only. Desk365 documentation notes that special access may be required. The contracts endpoint may be restricted to Premium plan users — verify access before building extraction scripts. |
| **Attachments** | No | Partial (via conversations endpoint) | JSON (URLs) | Attachment metadata and download URLs are returned in conversation responses. No bulk download endpoint. |
| **Automations / Workflows** | No | No | — | No export mechanism exists. Must be manually recreated. |
| **SLA Configurations** | No | No | — | SLA *names* appear on tickets, but the rules and escalation logic cannot be exported. |
| **Custom Views / Saved Filters** | No | No | — | Not exportable. Must be manually documented. |
| **Agent Roles & Permissions** | No | No | — | No API endpoint for role definitions or permission matrices. |
| **Macros / Canned Responses** | No | No | — | Not available in any export format. |

**Fully exportable:** ticket metadata, contacts, companies, time entries, surveys, contracts, and KB article content. **Partially exportable:** conversations, attachments, and KB article attachments — these require extra API steps or are only partly documented. **Not exportable:** admin configuration — automations, SLAs, roles, views, macros, and integration settings.

> [!WARNING]
> **[For engineering]** The native CSV ticket export silently drops all conversation data — replies, notes, and attachments are not included. If a custom field is deleted in the UI, its historical data on older tickets is also lost in the CSV export. You must use the API to capture the full state of any ticket object.

## How Do I Export Tickets from Desk365? (Native UI Export)

<cite index="3-5,3-6">When you export tickets from a helpdesk, you are essentially creating a copy of your ticket data in a different format, such as a CSV file. Desk365 makes it easy for you to export your tickets in just a few simple steps.</cite>

### Step-by-step: Exporting tickets from the agent portal

1. Log in to your Desk365 agent portal as an Administrator.
2. Navigate to the **Tickets** tab and select **All Tickets** from the Views list.
3. Click the **Export** button at the top of the ticket list.
4. In the export dialog, choose a time filter: **Created Time**, **Resolved Time**, or **Closed Time**.
5. Select the ticket fields, custom fields, and contact fields you want included.
6. Click **Export**. <cite index="3-10">You'll receive the exported file in your email inbox in .csv format.</cite>

### Five export modes in the native UI

<cite index="3-11">Several types of export options are available in Desk365: Standard ticket view, Current ticket view, Custom view, Search tickets, and Time entries.</cite>

| Export Mode | What It Covers | Best For |
|---|---|---|
| **All Tickets** (Standard view) | Every active ticket in your helpdesk | Full ticket metadata backup |
| **Current View** | Only tickets visible in your active view (e.g., "My Open and Pending") | Quick operational snapshots |
| **Custom View** | Tickets matching a saved custom filter (e.g., "Urgent tickets from Company X") | Targeted reporting |
| **Search Tickets** | Tickets matching a keyword search by subject, description, or ticket number | Ad-hoc investigation |
| **Time Entries** | Tickets with time tracking data, including billable hours | Client billing and time audits |

> [!WARNING]
> **Critical gotcha:** To export *all* tickets including archived ones, you must run two separate exports — one from the "All Tickets" view and one from the "Archived Tickets" view. Desk365 does not combine these automatically.

### Scheduled exports

<cite index="1-1">You can schedule a report to export the entire list of active tickets directly from the "All Tickets" view in your helpdesk.</cite> <cite index="1-3">Configure the export details like frequency, time, timezone, and recipients.</cite>

Scheduled exports support daily, weekly, or monthly frequencies. This is useful for recurring backup or reporting workflows without manual intervention. Scheduled exports are available on the **Plus** and **Premium** plans.

To set up: go to **Tickets > Actions > Scheduled Exports > New Schedule**, choose your frequency, recipients, and field selection.

**[For PMs]** Scheduled exports require zero engineering — any agent with the correct role permissions can configure them.

### Support portal export

End users can also export tickets from the Desk365 support portal. Available scopes include **All Tickets**, **Department or Company Tickets**, **Tickets Created by Me**, and **Tickets Shared with Me**. Admins control which fields appear in support portal exports from **Settings > Channels > Support Portal > Configure ticket export fields**.

### What the native export misses

The CSV export gives you ticket metadata: ticket number, subject, status, priority, agent, contact info, custom fields, timestamps, and duration metrics. It does **not** include:

- Conversation threads (replies and notes)
- Attachment files or URLs
- Full HTML description (unless the API is used with `include_description=1`)
- Knowledge base articles
- Survey responses (unless exported separately)
- Relationship data beyond contact-to-company mapping

**[For PMs]** If your goal is to audit the full history of customer interactions or migrate to another platform, the CSV export alone is insufficient. You need the API to get complete conversation threads and attachments.

## Export Methods: Every Way to Get Data Out of Desk365

There are six practical export methods. There is **no** publicly documented bulk backup API or direct database dump.

| Method | Data Coverage | Volume Limit | Speed | Complexity | Best For |
|---|---|---|---|---|---|
| **Agent Portal CSV** | Tickets, contacts, companies, time entries | No documented hard limit; view and date filters apply | Fast | Low | Quick reporting, PM audits, no engineering needed |
| **Support Portal CSV** | End-user-visible ticket scope only | Limited to user/company/shared scopes | Fast | Low | Customer self-service or DSAR-style ticket copies |
| **Scheduled Export** | Same as agent portal CSV | Same | Automated on schedule | Low | Recurring reporting and lightweight backups |
| **REST API v3** | All objects including conversations, KB, surveys, contracts | 10,000 tickets/hour ceiling; plan rate limits apply | Hours to days depending on volume | High | Full-fidelity extraction, migrations, compliance |
| **Power Automate** | Ticket-centric operations (create, update, get) | Connector-level limits apply | Varies | Medium | Event-driven sync, not bulk export |
| **Webhooks** | Real-time event payloads (ticket created, updated) | Event-driven, not historical | Real-time | Medium | Continuous data forwarding to external systems; not suitable for historical backups |

**[For PMs]** The agent portal CSV, support portal CSV, and scheduled exports require zero developer resources. API-based exports require a developer who can write pagination logic and handle rate limiting.

## API-Based Export: Endpoints, Pagination, and Rate Limits [For Engineering]

The Desk365 REST API v3 is the only way to extract full-fidelity data, including conversation threads, knowledge base content, and survey data.

### Authentication

<cite index="8-4">Each subdomain has its own unique API Key, which ensures that only authorized users can access data for that specific subdomain.</cite> The API key is passed in the `Authorization` header of every HTTP request. <cite index="10-1">Find your unique API key in the Desk365 portal: Go to Settings > Integrations > API and copy your API key.</cite>

**Multi-subdomain note:** If your organization operates multiple Desk365 subdomains (e.g., per business unit), each subdomain has an independent API key and data store. Exports must be run per-subdomain — there is no cross-subdomain API.

### Base URL format

<cite index="8-6">API requests must now include /v3 in the URL to ensure you're using the latest version.</cite>

```
https://<yoursubdomain>.desk365.io/apis/v3/tickets
```

Desk365's v3 API supersedes earlier versions. There is no publicly documented deprecation schedule for v2, but all new features and documentation reference v3 exclusively. Build all export scripts against v3.

### Core API endpoints for data export

| Endpoint | Method | Returns |
|---|---|---|
| `/v3/tickets` | GET | List of tickets with metadata, custom fields, survey ratings |
| `/v3/tickets/{ticket_number}/conversations` | GET | Replies, notes, and attachments for a single ticket (does **not** include original ticket description) |
| `/v3/contacts` | GET | Contact records with department associations |
| `/v3/companies` | GET | Company records with department lists |
| `/v3/time_entries` | GET | Time tracking data linked to tickets |
| `/v3/surveys` | GET | Survey configurations |
| `/v3/surveys/ratings` | GET | All survey ratings, ordered by creation time |
| `/v3/contracts` | GET | Contract records (may require special access / Premium plan) |
| `/v3/kb/categories` | GET | Knowledge base category structure and visibility settings |
| `/v3/kb/folders` | GET | Knowledge base folder hierarchy |
| `/v3/kb/articles` | GET | Full article content (HTML and plain text), view counts, statuses |

### Sample API response: Conversations endpoint

A truncated response from `GET /v3/tickets/{ticket_number}/conversations` illustrating the structure an export script must parse:

```json
{
  "conversations": [
    {
      "id": 204857,
      "ticket_number": 1042,
      "type": "reply",
      "incoming": false,
      "body": "<div>We've resolved the issue with your VPN access...</div>",
      "body_text": "We've resolved the issue with your VPN access...",
      "from_email": "agent@company.com",
      "to_emails": ["user@company.com"],
      "cc_emails": [],
      "created_time": "2024-11-15 14:32:18",
      "attachments": [
        {
          "name": "vpn-config.pdf",
          "size": 245760,
          "content_type": "application/pdf",
          "attachment_url": "https://yoursubdomain.desk365.io/attachments/download/abc123"
        }
      ]
    },
    {
      "id": 204901,
      "ticket_number": 1042,
      "type": "note",
      "private": true,
      "body": "<p>Escalated to network team — awaiting firewall rule change.</p>",
      "body_text": "Escalated to network team — awaiting firewall rule change.",
      "from_email": "agent@company.com",
      "created_time": "2024-11-15 15:10:44",
      "attachments": []
    }
  ]
}
```

**Key structural details:** Each conversation object includes `type` (reply or note), `private` (boolean for internal notes), `body` (HTML) and `body_text` (plain text), and an `attachments` array with `name`, `size`, `content_type`, and `attachment_url`. The original ticket description is **not** present in this response — it must be retrieved from the ticket object with `include_description=1`.

### Pagination

<cite index="8-9,8-10">Version 3 brings a significant improvement to how many tickets you can retrieve in one call. You can now choose to retrieve 30, 50, or 100 tickets per call using the `ticket_count` parameter.</cite>

Pagination uses an `offset` parameter. To walk through all tickets:

```python
import requests
import time
import json
import re

API_KEY = "your-api-key"
BASE_URL = "https://yoursubdomain.desk365.io/apis/v3"
HEADERS = {"Authorization": API_KEY}

def export_all_tickets():
    all_tickets = []
    offset = 0
    page_size = 100

    while True:
        params = {
            "ticket_count": page_size,
            "offset": offset,
            "include_description": 1,
            "include_custom_fields": 1,
            "include_survey_details": 1,
            "order_by": "updated_time",
            "order_type": "asc"
        }
        response = requests.get(f"{BASE_URL}/tickets", headers=HEADERS, params=params)

        if response.status_code == 429:
            # Retry-After header behavior is not confirmed in Desk365 docs.
            # Default to 60s as a defensive fallback.
            retry_after = int(response.headers.get("Retry-After", 60))
            print(f"Rate limited. Waiting {retry_after}s...")
            time.sleep(retry_after)
            continue

        response.raise_for_status()
        data = response.json()
        tickets = data.get("tickets", [])

        if not tickets:
            break

        all_tickets.extend(tickets)
        offset += page_size

        # Respect rate limits (Standard: ~1.6 req/min; Plus/Premium: 50 req/min)
        time.sleep(1.2)  # Safe for Plus/Premium plans

    return all_tickets


def export_conversations(ticket_number):
    """Fetch all conversations for a single ticket.
    Note: This does NOT include the original ticket description."""
    url = f"{BASE_URL}/tickets/conversations"
    params = {"ticket_number": ticket_number}
    response = requests.get(url, headers=HEADERS, params=params)

    if response.status_code == 429:
        time.sleep(int(response.headers.get("Retry-After", 60)))
        return export_conversations(ticket_number)

    response.raise_for_status()
    return response.json()


def extract_inline_images(body_html):
    """Parse HTML body for inline images that need to be downloaded
    and re-hosted during migration. Handles both URL-referenced and
    base64-encoded images."""
    img_urls = []
    if not body_html:
        return img_urls

    # Find all <img> src attributes
    img_tags = re.findall(r'<img[^>]+src=["\']([^"\']+)["\']', body_html)
    for src in img_tags:
        if src.startswith("data:image/"):
            # Base64-encoded inline image — decode and save separately
            img_urls.append({"type": "base64", "data": src})
        elif "desk365.io" in src or src.startswith("http"):
            # Hosted image — download via URL
            img_urls.append({"type": "url", "url": src})
    return img_urls
```

### Rate limits

Desk365's API rate limits are plan-specific:

| Plan | Rate Limit | Max Tickets/Hour | Cost/User/Month |
|---|---|---|---|
| **Standard** | <cite index="25-2">100 API calls per hour</cite> | ~10,000 (at 100 tickets/call) | $12 |
| **Plus** | 50 API calls per minute | ~300,000 (at 100 tickets/call) | $20 |
| **Premium** | 50 API calls per minute | ~300,000 (at 100 tickets/call) | $32 |

**Clarification on "Max Tickets/Hour":** The 10,000 figure is the practical ceiling for ticket *list* extraction — 100 calls × 100 tickets per call. However, conversation extraction requires one additional call per ticket, which is where the rate limit becomes the bottleneck. Plus/Premium plans handle this far more efficiently because their rate limit is per-minute rather than per-hour.

> [!CAUTION]
> **[For engineering]** The Standard plan's 100 calls/hour limit is extremely restrictive for bulk exports. If you have more than a few thousand tickets with conversations, either upgrade to Plus/Premium before starting the export or plan for a multi-day extraction window.

### Throughput math

Ticket list extraction alone can run at about 10,000 tickets per hour on any plan. But full-fidelity exports are dramatically slower because the conversations endpoint requires at least one additional call per ticket.

**Plus/Premium example:** For a helpdesk with 10,000 tickets averaging 5 conversations each, you need 100 ticket-list calls plus 10,000 conversation calls — roughly 10,100 total API calls. At 50 calls per minute, that's about 202 minutes (3.4 hours), not counting attachment downloads.

**Standard example:** Those same 10,100 calls at 100 calls per hour would take approximately 101 hours — over 4 days of continuous extraction.

For 50,000 tickets on Plus/Premium, expect roughly 16–17 hours of API extraction time before attachment downloads begin.

### Key API behaviors to watch

- **Description is excluded by default.** You must pass `include_description=1` to get ticket body content. This is a documented parameter in the Desk365 API v3 reference.
- **Custom fields use the `cf_` prefix.** All custom field keys in v3 responses are prefixed (e.g., `cf_department`, `cf_employee_id`). Custom field API labels are permanent once created — choose them carefully.
- **Null values are explicit.** Fields with no data return `null` rather than being omitted from the response.
- **Survey data requires opt-in.** Set `include_survey_details=1` to get CSAT/NPS ratings inline with ticket data.
- **`updated_since` filter** lets you do incremental exports — only tickets modified after a given timestamp are returned. This is a documented filter parameter in the v3 API. Useful for scheduled backup scripts and delta migrations.
- **Source constants** are integers you will need to normalize: 1 = Email, 5 = Microsoft Teams, 6 = Support Portal, 7 = Phone/Other, 12 = Web Form, 13 = Web Widget, 15 = API.
- **Throttle error behavior:** Desk365's public documentation does not confirm whether a `Retry-After` header is returned on HTTP 429 responses. Implement exponential backoff as a defensive measure — start at 60 seconds and double on consecutive failures.
- **Custom field types are returned as strings.** Numeric fields like `cf_employee_id` and date fields will be string-typed in JSON responses. Cast types explicitly before importing into a target system.

## Does Desk365 Let You Export Attachments?

Desk365 does **not** include attachment files in CSV exports. Attachments are only accessible through the API's conversations endpoint, where each conversation entry includes an `attachments` array with `name`, `size`, `content_type`, and `attachment_url` (see the sample JSON response above).

To export all attachments from a Desk365 instance:

1. Fetch all tickets via `/v3/tickets`.
2. For each ticket, call the conversations endpoint to get reply/note objects.
3. Parse the `attachments` array from each conversation entry.
4. Download each file using the provided `attachment_url`.

There is no bulk attachment download endpoint. Each file must be fetched individually — and each download counts against your API rate limit. Desk365 allows up to **10 files per conversation** with a **20 MB combined limit** per conversation in the editor, so attachment volume can grow quickly across thousands of tickets.

**Inline images** embedded in HTML reply bodies are a separate edge case. These are typically hosted on Desk365's servers as URLs within the HTML body. Some — particularly those pasted from Outlook or Teams — may also be stored as base64-encoded strings within the HTML, or contain Microsoft-specific namespaces (e.g., `<o:p>`, `<v:shape>`). If you're migrating to another platform, these image URLs will break unless you download and re-host them. Your export script must parse the `body_html` of every conversation, identify `<img>` tags, and download those image sources separately. The `extract_inline_images()` function in the code sample above demonstrates this pattern.

For KB articles, the API exposes a `has_attachments` flag, but bulk retrieval of article attachments is not well-documented. Test retrieval on a sample article before building extraction logic.

## What Data Cannot Be Exported from Desk365?

Some data types have no export path — not through the UI, not through the API. This is the hard constraint that determines your switching cost.

| Data Type | Exportable? | Workaround |
|---|---|---|
| Automation rules / triggers | No | Manually document every rule (trigger condition, action, order) and recreate in the target platform |
| SLA rule configurations | No | SLA *names* appear on tickets, but escalation rules, business hours, and target metrics must be manually rebuilt |
| Custom views / saved filters | No | Screenshot or document filter criteria (field, operator, value) before migrating |
| Agent roles & permission matrices | No | Manual documentation required — export a matrix of role names × permission flags |
| Macros / canned responses | No | Copy-paste from the UI; no API endpoint exists |
| Audit trail / field change logs | Partial | <cite index="62-13">Desk365 achieves this through detailed encrypted field logs that record every addition, update, and deletion made to database records.</cite> No documented API endpoint to bulk-export these logs; contact Desk365 support to request access. |
| Deleted / permanently deleted records | No | Once a ticket or contact is permanently deleted, it is gone. There is no "recycle bin" endpoint. Permanently deleting a contact also removes related ticket history. |
| Integration configurations | No | Power Automate flows, Jira links, Azure DevOps connections must be recreated manually |
| Custom ticket forms | No | Form structure and field mapping must be documented manually |
| Analytics dashboards | Partial | Report CSVs can be downloaded, but those are summary outputs — not full object exports |

### Comparison: Desk365 vs. peers on configuration exportability

For context, here is how Desk365's admin-configuration exportability compares to two common mid-market alternatives:

| Config Object | Desk365 | Freshdesk | Zendesk |
|---|---|---|---|
| Automations / triggers | Not exportable | Not exportable via UI; API read access available | Fully exportable via API (`/api/v2/triggers`) |
| SLA policies | Not exportable | API read access available | Fully exportable via API (`/api/v2/slas/policies`) |
| Macros / canned responses | Not exportable | API read access available | Fully exportable via API (`/api/v2/macros`) |
| Custom roles | Not exportable | API read access (Enterprise only) | Fully exportable via API |

Desk365's gap is that **no** admin configuration object has API read access. Freshdesk provides read-only API access to most configuration objects. Zendesk exposes nearly all admin objects through its API. This is the single largest differentiator in switching cost between these platforms.

**[For CTOs]** The inability to export automation rules, SLA configurations, and macros is the single largest hidden switching cost. For teams with complex workflow automations (10+ rules with conditional branching), budget 20–40 hours of manual re-creation work during any migration.

## Data Format, Encoding, and Cleanup After Export

### File formats and field naming

- **Native exports:** CSV only, delivered via email.
- **API responses:** JSON, UTF-8 encoded.
- **Rich-text fields:** Desk365 exposes both HTML and plain-text variants. Tickets have `description` and `description_text`. Conversations have `body` and `body_text`. KB articles have `article_content` and `article_content_text`.

### Common data quality issues

- **Microsoft-specific HTML markup.** Because Desk365 ingests data from Microsoft Teams, Outlook, and web portals, the HTML in ticket descriptions and replies is often inconsistent. Desk365 data frequently includes Microsoft-specific HTML namespaces like `<o:p>`, `<v:shape>`, and `mso-` CSS properties generated by Outlook's rendering engine. If you import this raw HTML into a platform like Zendesk or Jira Service Management, it can break ticket rendering or produce unreadable formatting. Sanitize with a library like Python's `bleach` or `lxml` before import — strip `mso-*` styles and Office namespace tags.

- **Timezone handling.** API timestamps use the format `YYYY-MM-DD HH:MM:SS`. Desk365 does not include timezone offset information in API responses. Verify empirically whether these are UTC or account-timezone-local by comparing a known ticket's API timestamp against its UI-displayed time. Ensure your destination system is configured accordingly.

- **Custom field type mismatches.** Custom fields in the API response are all returned as strings, even numeric fields like `cf_employee_id` or date fields. Cast types appropriately before importing. Build a type map from your Desk365 custom field configuration to avoid silent data corruption.

- **Source constants.** Desk365 uses integer source constants (1 = Email, 5 = Teams, 6 = Support Portal, 7 = Phone/Other, 12 = Web Form, 13 = Web Widget, 15 = API) that you will need to normalize for your destination system's channel model.

- **Orphaned contacts.** Contacts not associated with a company will export without a `company_name` value. Ensure your import logic handles null company references.

- **Duplicate records.** If you export from multiple views (e.g., All Tickets + Archived Tickets via the UI), deduplicate on `ticket_number` before loading into a target system. Desk365 can also create duplicate contact records if a user emails from an alias not mapped in Azure AD — deduplicate on email address, not contact name.

### Post-export validation checklist [For PMs]

- [ ] Record count matches: compare exported row count against Desk365's ticket count in the dashboard — count active and archived tickets separately
- [ ] Spot-check 10 tickets for field accuracy (status, priority, agent, timestamps)
- [ ] Verify custom field values are present and correctly typed
- [ ] Confirm conversation thread count matches for sampled tickets — verify the original ticket description is included alongside conversation data
- [ ] Validate attachment download URLs are accessible (test 5–10 URLs manually)
- [ ] Check for encoding issues in non-English text (look for garbled characters, especially in CJK or accented-character content)
- [ ] Confirm date/time values are in the expected timezone
- [ ] Verify department, company, watcher, and `share_to` relationships where used
- [ ] Cross-reference survey ratings count against Desk365 dashboard totals

> [!TIP]
> **Fastest safe PM approach:** Run native CSV exports first for control totals and stakeholder review, then run API extraction for full fidelity. This two-layer approach catches archived-ticket misses early and gives engineering a stable reconciliation target.

## Export for Migration vs. Backup vs. Compliance

Your export strategy must match your business goal. If you use the same export for all three, you will either overbuild a report or underbuild a migration.

### Migration

A migration export must preserve **relationships** — tickets linked to contacts, contacts linked to companies, conversations threaded to tickets, attachments linked to messages. The native CSV export breaks most of these relationships because it flattens data into a single table. For migration, the API is the only viable path.

Key requirements:

- Map Desk365 `ticket_number` to the target system's internal ID scheme
- Preserve conversation chronology (agent replies, customer replies, notes in order)
- Remember that `/v3/tickets/conversations` omits the original ticket description — you must combine ticket description data from the ticket endpoint with `include_description=1`
- Re-host inline images and attachments
- Sanitize Microsoft-specific HTML markup before importing into the target platform
- Recreate custom fields in the target system before importing
- Manually rebuild automations, SLAs, macros, and views (budget 20–40 hours for complex configurations)

For a detailed approach to migrating between helpdesk platforms, see our [help desk data migration playbook](https://clonepartner.com/blog/blog/help-desk-data-migration-playbook/).

### Backup

Desk365 does not offer a built-in full-account backup feature. For backup purposes, combine a weekly scheduled CSV export of ticket metadata with periodic API-based snapshots of conversations and KB articles. JSON is the best format for backup snapshots because it preserves field types, nested structures, and relationship data.

Use the API's `updated_since` filter to pull only modified tickets and dump results into cloud storage (Azure Blob, S3, or SharePoint) on a cron schedule. A practical backup cadence:

- **Daily:** Incremental ticket metadata + conversations for tickets updated in the last 24 hours
- **Weekly:** Full KB article snapshot
- **Monthly:** Full ticket list + contact/company export for reconciliation

Scheduled CSV export alone is not enough for full restoration — it misses attachments, conversations, KB content, and admin configuration.

### Compliance (GDPR, DSAR)

<cite index="62-3,62-4">At Desk365, we place a high priority on user privacy and data protection. We have implemented a range of measures to ensure full compliance with GDPR, offering customers enhanced control over their data.</cite>

<cite index="62-1">Desk365 strictly adheres to recognized industry security standards, such as SOC 2 Type 2.</cite> <cite index="62-7">They also comply with HIPAA within the Premium pricing plan.</cite>

For GDPR Article 20 (right to data portability), <cite index="64-9">organisations must provide the data in structured, common, machine-readable formats such as CSV, JSON, or XML, within one month of a valid request.</cite> Desk365's CSV and JSON export capabilities satisfy this format requirement.

To fulfill a data-subject access request (DSAR), use the API to filter tickets by the contact's email address, then fetch all conversations for matching tickets. There is no one-click "export all data for this person" button in the UI — DSAR fulfillment requires API scripting. Desk365 does not document a self-serve GDPR portability package or standalone audit-log export. For deletion requests under GDPR Article 17, note that permanently deleting a contact also removes related ticket history — confirm with your DPO whether this meets your retention requirements.

## Is Desk365 Data Portable? Vendor Lock-In Assessment [For CTOs]

**Portability rating: Mostly Portable (estimated 80–85% of operational data exportable; 15–20% requires manual rebuild)**

| Dimension | Assessment |
|---|---|
| Ticket metadata | Fully exportable via CSV and API |
| Conversation history | Fully exportable via API (per-ticket calls required) |
| Contacts & companies | Fully exportable via CSV and API |
| Knowledge base content | Fully exportable via API (HTML + plain text) |
| Attachments | Exportable via API (individual URL downloads, no bulk endpoint) |
| Surveys & ratings | Fully exportable via API |
| Time entries | Fully exportable via CSV and API |
| Contracts | Exportable via API (may require Premium plan) |
| Automations & workflows | **Not exportable** — must be rebuilt |
| SLA rules | **Not exportable** — must be rebuilt |
| Custom forms & views | **Not exportable** — must be documented manually |
| Roles & permissions | **Not exportable** — must be rebuilt |
| Macros / canned responses | **Not exportable** — must be rebuilt |

The "80–85% portable" figure covers all customer-facing and operational data: tickets, conversations, contacts, companies, KB content, attachments, surveys, time entries, and contracts. The remaining 15–20% is admin configuration: automations, SLAs, custom views, roles, macros, and integration settings. These must be manually documented from the UI and recreated in the target system.

This portability profile is comparable to Freshdesk, which also lacks UI-based admin export but provides API read access to automation rules. Desk365 falls short of Zendesk, which exposes automations, triggers, macros, SLAs, and roles via API. It is significantly better than platforms that restrict data export contractually or charge export fees.

Desk365 does not impose contractual restrictions on data export. <cite index="46-4">When you cancel, you have time to close tickets, export any needed data, and inform your team.</cite> There are no documented data hostage clauses, export surcharges, or time-limited export windows after cancellation.

The real switching cost is engineering time: building API extraction scripts, handling pagination and rate limits, downloading attachments, sanitizing HTML, and rebuilding the configuration layer.

## How Long Does a Full Desk365 Export Take? [For PMs]

| Dataset Size | Native UI Export | API Export (Plus/Premium) | API Export (Standard) |
|---|---|---|---|
| **Small** (<5,000 tickets) | 5–15 minutes | 2–4 hours (with conversations) | 1–2 days |
| **Medium** (5,000–50,000 tickets) | 15–60 minutes (metadata only) | 1–3 days | 1–2 weeks |
| **Large** (50,000+ tickets) | Hours (metadata only) | 3–7 days | Not practical — upgrade plan first |

These estimates assume continuous extraction with proper rate limiting. Attachment downloads can add 30–100% additional time depending on volume and file sizes.

### Phase breakdown for a full export project

| Phase | Effort | Who |
|---|---|---|
| Scoping & field mapping | 2–4 hours | PM + engineer |
| API key provisioning | 15 minutes | Admin |
| Script development | 4–8 hours | Developer |
| Extraction run | Varies (see table above) | Automated |
| Validation & spot-checks | 2–4 hours | PM + engineer |
| Data cleanup & transformation | 4–16 hours | Engineer |
| **Total (medium dataset)** | **2–5 days** | **1 developer + 1 PM** |

### Minimum team composition

- **UI-only export:** 1 admin or PM, no developer needed
- **API export:** 1 developer (Python, JavaScript, or similar) + 1 PM for validation
- **Full migration with attachments and HTML sanitization:** 1–2 developers + 1 PM

## Using Power Automate as an Export Channel

<cite index="15-1">Integrate Desk365 with in-house or third-party apps and services using the Desk365 API/Webhook or using the Desk365 Power Automate connector.</cite>

The Desk365 Power Automate connector supports triggers (ticket created, updated, note added, reply added) and actions (create, update, get ticket). <cite index="13-15,13-16">The connector provides an action to get all tickets, and you can customize your query based on filters.</cite>

Power Automate is useful for **real-time sync** scenarios — forwarding new tickets to a secondary system, appending notes to a SharePoint list — but it is not designed for bulk historical exports. The connector processes one event at a time and does not support offset-based pagination for historical data retrieval.

Desk365 also supports outbound webhooks, which can push event payloads to external endpoints when tickets are created or updated. This is useful for real-time data forwarding (e.g., to a data warehouse or logging service) but does not cover historical data and cannot replace API-based bulk extraction.

**[For PMs]** If you're already in the Microsoft 365 ecosystem, Power Automate can bridge Desk365 to SharePoint, Excel Online, or Dynamics 365 for ongoing data flows. For a one-time full export, use the REST API directly.

## When to Bring In Help

For teams with fewer than 5,000 tickets and no attachment requirements, the native CSV export is usually sufficient for reporting and basic backups. For datasets above 10,000 tickets, or when you need conversations, attachments, and knowledge base content preserved with full fidelity, the API is the only path — and it requires someone comfortable writing pagination logic, handling rate limits, sanitizing Microsoft HTML, and validating data integrity.

**Disclosure:** ClonePartner is a data migration service provider. We have a commercial interest in this topic. The technical content in this guide is based on Desk365's publicly documented API (v3) and native export features, supplemented by operational experience with the platform.

If you'd rather not build and maintain export scripts, we handle the full extraction and deliver validated, import-ready data. For comparison of portability patterns across helpdesks, see our [Freshdesk export guide](https://clonepartner.com/blog/blog/how-to-export-data-from-freshdesk-methods-api-limits-mapping/) and [Zoho Desk export guide](https://clonepartner.com/blog/blog/how-to-export-data-from-zoho-desk-methods-limits-api-guide/).

> Need to export data from Desk365 for a migration, backup, or compliance project? Our engineers handle the full extraction — tickets, conversations, attachments, and knowledge base — so your team doesn't have to write a single line of code.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### Can I export all my data from Desk365?

You can export most operational data — tickets, contacts, companies, conversations, time entries, knowledge base articles, surveys, and contracts — using a combination of the native CSV export and the REST API v3. Automation rules, SLA configurations, custom views, macros, and role permissions are not exportable through any method and must be manually recreated.

### Does Desk365 export include attachments?

Native CSV exports do not include attachments. The API's conversations endpoint returns attachment metadata (filename, size, MIME type) and a download URL for each file. You must download each attachment individually — there is no bulk attachment export endpoint.

### What are the Desk365 API rate limits?

The Standard plan allows 100 API calls per hour. The Plus and Premium plans allow 50 API calls per minute. You can retrieve up to 100 tickets per call, with a maximum of 10,000 ticket records per hour.

### How long does it take to export data from Desk365?

A native CSV export of ticket metadata typically completes within minutes for datasets under 10,000 records. A full API export with conversations and attachments for 10,000 tickets takes 2-4 hours on Plus/Premium plans, or multiple days on the Standard plan due to its 100 calls/hour limit.

### Can I export Desk365 data for GDPR compliance?

Desk365 supports GDPR data portability through its CSV and JSON export capabilities. To fulfill a data-subject access request, use the API to filter tickets and conversations by the contact's email address. There is no single-click 'export all data for this person' feature — DSAR fulfillment requires some scripting.