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.

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.

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.

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

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.

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. You'll receive the exported file in your email inbox in .csv format.

Five export modes in the native UI

Several types of export options are available in Desk365: Standard ticket view, Current ticket view, Custom view, Search tickets, and Time entries.

Scheduled exports

You can schedule a report to export the entire list of active tickets directly from the "All Tickets" view in your helpdesk. Configure the export details like frequency, time, timezone, and recipients.

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.

[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

Each subdomain has its own unique API Key, which ensures that only authorized users can access data for that specific subdomain. The API key is passed in the Authorization header of every HTTP request. Find your unique API key in the Desk365 portal: Go to Settings > Integrations > API and copy your API key.

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

API requests must now include /v3 in the URL to ensure you're using the latest version.

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

Sample API response: Conversations endpoint

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

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

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.

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

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:

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.

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.

Comparison: Desk365 vs. peers on configuration exportability

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

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

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.

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)

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.

Desk365 strictly adheres to recognized industry security standards, such as SOC 2 Type 2. They also comply with HIPAA within the Premium pricing plan.

For GDPR Article 20 (right to data portability), organisations must provide the data in structured, common, machine-readable formats such as CSV, JSON, or XML, within one month of a valid request. 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)

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. When you cancel, you have time to close tickets, export any needed data, and inform your team. 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]

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

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

Integrate Desk365 with in-house or third-party apps and services using the Desk365 API/Webhook or using the Desk365 Power Automate connector.

The Desk365 Power Automate connector supports triggers (ticket created, updated, note added, reply added) and actions (create, update, get ticket). The connector provides an action to get all tickets, and you can customize your query based on filters.

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 and Zoho Desk export guide.