How to Export Data from SolarWinds Service Desk: Methods & Limits

How to Export Data from SolarWinds Service Desk: Methods & Limits

Exporting data from SolarWinds Service Desk (formerly Samanage) means navigating two entirely different systems: a limited UI for CSV dumps, and the Samanage REST API for full-fidelity relational data. If you only need a flat list of recent tickets for a spreadsheet, the native UI works. If you are migrating to a new ITSM platform, running compliance audits, or extracting attachments and CMDB relationships, you must use the API.

This guide covers exactly how to extract your data from SolarWinds Service Desk: which objects export cleanly, the actual rate limits of the Samanage API, which fields silently drop during export, how to handle attachments, comments, and ITIL relationships once the data is out, and what happens when things go wrong mid-extraction.

What Data Can You Export from SolarWinds Service Desk?

SolarWinds Service Desk (SWSD), originally built as Samanage before SolarWinds acquired it in 2019, follows a standard ITIL data model. The underlying API still reflects the Samanage architecture — documentation, endpoints, and authentication all use the legacy domain.

Here is the export availability for each core object:

The layout parameter on API GET requests is critical. The default short layout omits custom fields, comments, and nested objects. Always use layout=long for export. SolarWinds' February 2024 release notes changed the custom field naming to custom_fields_values and added hourly filtering support, so scripts built against stale field names will break silently — values will simply be absent from responses rather than triggering errors. (documentation.solarwinds.com)

Detecting schema drift: Before running a full export, pull a single record with layout=long and diff the field names against your script's expected schema. If SolarWinds renames or restructures fields (as happened in February 2024), this single-record check catches it before you process 100,000 records with missing data.

Every Way to Get Data Out of SolarWinds Service Desk

There are five practical methods to extract data from SWSD. Each trades off coverage, speed, and complexity differently. There is no direct database access — SWSD is a SaaS product.

SolarWinds also offers a weekly scheduled CSV backup of product data, which serves as a baseline safety net. This backup covers primary data objects but is not a full-fidelity snapshot — attachments, audit trails, and configuration data are not included. (solarwinds.com)

Webhook-based extraction: SWSD supports outbound webhooks that fire on record creation and update events. While not a bulk export mechanism, webhooks provide near-real-time data streaming for ongoing sync use cases — for example, feeding ticket data into a data warehouse or BI tool as events occur rather than polling the API on a schedule. Webhooks are configured under Setup → Integrations and deliver JSON payloads to your specified endpoint. This does not replace API-based bulk export but can supplement it for incremental sync after the initial extraction.

Zero-engineering paths are UI export, report export, and the scheduled CSV backup. Developer time starts when you need API pagination, comment walking, attachment downloads, or relationship preservation.

Third-party ETL or BI tools (Pipedream, Portable, etc.) sit on top of these same primitives. They can help with warehousing, but they still inherit SolarWinds' pagination and rate limits and typically don't handle attachments or relationship repair on their own.

Native UI Export: Step-by-Step

The fastest way to get data out without writing code.

1. Navigate to the module you want to export (e.g., Service Desk → Incidents, Assets → Computers, or Setup → Users).
2. Apply any filters or saved views to scope the export.
3. Click the Columns (gear) icon to modify visible columns. This step matters: the CSV export only includes columns currently displayed in your view. Add custom fields, assignee data, and resolution codes before exporting.
4. Click the Actions button (top right of the index page).
5. Select Export → CSV - Current View (or CSV - All Columns, XML, PDF).
6. If the result set is 200 rows or fewer, the file downloads immediately. For larger sets, SWSD queues the export and emails you a download link. (documentation.solarwinds.com)

Depending on the amount of data being exported, it can take a few hours for you to receive an email notification that the export is complete. SolarWinds recommends opening a support ticket if an export takes longer than 24 hours.

What you get: A CSV file containing the columns from your current view.

What you lose:

• Attachments and screenshots are never included.
• Full comment threads are truncated or omitted.
• Relationship references (linked problems, parent CIs) flatten to IDs without context.
• Custom field values may not appear unless included in your view.
• Exported CSV columns differ from import template columns — exported CSVs cannot be used directly for re-import into SWSD. The import template has a fixed schema available under Setup → Import, while export columns reflect your current view configuration. (documentation.solarwinds.com)

Report-based exports offer an alternative path: navigate to Analytics → Reports, configure or select a report, then use the three-dot menu to Schedule report with CSV delivery via email. This is the only way to automate recurring exports without code.

API-Based Export: Authentication, Endpoints, and Rate Limits

The Samanage REST API is the primary method for any serious data export from SolarWinds Service Desk.

Plan Requirements

Authentication

The API uses JSON Web Token (JWT) bearer authentication. Only administrators can generate tokens. There is no OAuth flow or service account mechanism — all API access is tied to a specific admin user's token.

1. Navigate to Setup → Users & Groups → Users.
2. Locate your admin user and open the detail page.
3. Click Actions → Generate JSON Web Token.
4. Save the token securely — regenerating it invalidates all previous tokens immediately, breaking any scripts or integrations using the old token.

Pass the token in every request header:

curl -H "X-Samanage-Authorization: Bearer YOUR_TOKEN" \
     -H "Accept: application/vnd.samanage.v2.1+json" \
     https://api.samanage.com/incidents.json?per_page=100&page=1

Common authentication errors:

API Versioning

The current API version is v2.1, specified via the Accept header. SolarWinds does not publish a formal API deprecation policy or timeline for retiring older API versions. If you are building long-lived integrations, pin to v2.1 and monitor SolarWinds release notes for breaking changes — the February 2024 custom field rename is an example of a non-versioned breaking change that affected existing integrations without a version bump.

Regional API Endpoints

SWSD runs on region-specific infrastructure. Your API base URL must match your tenant's region:

Using the wrong regional endpoint returns 401 Unauthorized errors that don't indicate the root cause is a region mismatch. If you're getting unexplained 401s with a valid token, check this first.

Core Export Endpoints

Pagination

List endpoints use page-number pagination with two parameters:

• page — integer, starts at 1
• per_page — integer, default 25, maximum 100

The total record count is returned in the X-Total-Count response header for most endpoints. Additional response headers include X-Per-Page, X-Total-Pages, and Link. The solutions endpoint is a known exception — it does not return X-Total-Count, so you must page until you receive an empty array.

All list responses are JSON arrays. Individual record responses are wrapped in object-key wrappers: {"incident": {...}}, {"user": {...}}, etc.

Mid-pagination record changes: If records are created, modified, or deleted while you are paginating through results, you may encounter duplicates (a record shifts to a later page after an insert) or missed records (a record shifts to an earlier page after a deletion). For migration-grade exports, use date-range filters (created_at or updated_at) to lock the window of records you are extracting, then run a second pass for records updated during the extraction.

Rate Limits

The SolarWinds plan comparison page lists up to 150 API calls per user per minute, with specific user-provisioning calls supporting up to 1,500 per user per minute. (solarwinds.com)

However, the API reference itself does not publish precise numeric limits, which makes export planning frustrating. What we know from operational experience:

• Sustained request rates above ~10 requests/second trigger throttling.
• Throttled responses return HTTP 429 Too Many Requests.
• There is no reliably documented Retry-After header, though some tenants return one intermittently.
• Conservative safe throughput: 1 request every 1–2 seconds.
• Rate limit scope: Limits appear to be per-token (per-user), not per-tenant. Multiple admin tokens may allow parallel extraction streams, but this is not officially documented and risks triggering tenant-level blocks.
• Concurrent requests: Running multiple threads with the same token counts all requests against the same rate bucket. Two threads at 5 req/sec = 10 req/sec against the same limit.

Older mirrored API docs quote legacy higher limits (1,000–1,500 calls per minute depending on plan). For current planning, use 150/minute unless SolarWinds support confirms a higher limit for your specific tenant.

Build your export scripts with exponential backoff starting at 2 seconds. Log every 429 response with a timestamp so you can empirically determine your tenant's actual threshold before committing to a full extraction timeline.

Extraction Script (Python)

Here is a production-safe pattern for paginated extraction with retry logic:

import requests
import time
import json
import random
import logging
 
logging.basicConfig(level=logging.INFO, format='%(asctime)s %(levelname)s %(message)s')
 
BASE_URL = "https://api.samanage.com"
TOKEN = "YOUR_JWT_TOKEN"
HEADERS = {
    "X-Samanage-Authorization": f"Bearer {TOKEN}",
    "Accept": "application/vnd.samanage.v2.1+json"
}
 
MAX_RETRIES = 5
 
def export_all(endpoint, output_file, extra_params=None):
    page = 1
    per_page = 100
    all_records = []
    consecutive_errors = 0
 
    while True:
        params = {"page": page, "per_page": per_page, "layout": "long"}
        if extra_params:
            params.update(extra_params)
 
        url = f"{BASE_URL}/{endpoint}"
 
        try:
            response = requests.get(url, headers=HEADERS, params=params, timeout=60)
        except requests.exceptions.RequestException as e:
            logging.error(f"Network error on page {page}: {e}")
            consecutive_errors += 1
            if consecutive_errors >= MAX_RETRIES:
                logging.error(f"Max retries reached at page {page}. Saving partial results.")
                break
            time.sleep(min(60, 2 ** consecutive_errors) + random.random())
            continue
 
        if response.status_code == 401:
            logging.error("Authentication failed (401). Check token and regional endpoint.")
            break
 
        if response.status_code == 403:
            logging.error(f"Permission denied (403) on {endpoint}. Check user role permissions.")
            break
 
        if response.status_code == 404:
            logging.warning(f"Endpoint not found (404): {endpoint}. Skipping.")
            break
 
        if response.status_code in (429, 500, 502, 503, 504):
            consecutive_errors += 1
            if consecutive_errors >= MAX_RETRIES:
                logging.error(f"Max retries ({MAX_RETRIES}) reached at page {page}. Saving partial results.")
                break
            retry_after = int(response.headers.get("Retry-After", 0) or 0)
            wait = retry_after or min(60, 2 ** consecutive_errors) + random.random()
            logging.warning(f"Retryable error {response.status_code} on page {page}. "
                          f"Waiting {wait:.1f}s (attempt {consecutive_errors}/{MAX_RETRIES})...")
            time.sleep(wait)
            continue
 
        response.raise_for_status()
        consecutive_errors = 0  # reset on success
        data = response.json()
 
        if not data:  # empty array = last page
            break
 
        all_records.extend(data)
        total_count = response.headers.get("X-Total-Count", "unknown")
        logging.info(f"Page {page}: {len(data)} records (cumulative: {len(all_records)}, "
                    f"total available: {total_count})")
        page += 1
        time.sleep(1)  # stay under rate limits
 
    with open(output_file, "w") as f:
        json.dump(all_records, f, indent=2)
 
    return len(all_records)
 
# Export incidents with full detail
total = export_all("incidents.json", "swsd_incidents.json")
logging.info(f"Exported {total} incidents")
 
# Export with date-range filter to avoid mid-pagination drift
total = export_all(
    "incidents.json",
    "swsd_incidents_2024.json",
    extra_params={"created_at[]": "2024-01-01", "created_at[]": "2024-12-31"}
)

Error codes you will encounter during extraction:

Exporting Attachments and Inline Media

Attachments do not come out in CSV exports or standard API list responses. They require a separate extraction stream entirely.

When you query an incident with layout=long, the JSON payload includes an attachments array. Each attachment object contains metadata (filename, size, content type) and a URL. These URLs are pre-signed AWS S3 links pointing to files stored in SolarWinds' S3 infrastructure.

Critical constraints:

• URLs expire. Pre-signed S3 URLs have a limited validity window (typically minutes to hours, not days). Your extraction script must parse the JSON and immediately download each file. You cannot export the JSON, wait a week, then download the files.
• No bulk download endpoint. Each attachment is a separate HTTP GET request.
• File size limit: Individual uploads are capped at 25 MB, and attachment settings also apply to API calls. (documentation.solarwinds.com)
• Inline images pasted into incident descriptions or KB articles are stored as hosted assets referenced via internal URLs. You must parse the HTML body of the description field, find image src URLs, download those files, and rewrite the HTML to point to your destination platform. These URLs will break if your SolarWinds instance is deactivated.
• Comments carry attachments too. You must iterate through every incident and every comment on each incident to discover all files.
• Attachment downloads count against your rate limit. Each file download is an API call. 10,000 incidents × 1.5 attachments per incident = 15,000 additional API calls, or roughly 4 hours at 1 req/sec.

If your migration requires attachments, add 30–50% to your time estimate for attachment extraction alone.

What Data Cannot Be Exported from SolarWinds Service Desk?

No platform allows 100% data portability. The following data categories have no export path — not through the UI, not through the API:

The audit trail endpoint (/audits.json) provides read-only access to tenant-wide change history with field-level before/after values, which partially compensates for the inability to export workflow configurations — you can see what was changed, by whom, and when, which helps reconstruct business logic during migration.

What your team retains post-migration: Ticket content, user records, asset inventories, CMDB relationships, and KB articles are all fully exportable. What you lose are the operational configurations — the rules, automations, and workflows that define how your service desk behaves. These must be rebuilt in any target platform.

Data Format, Encoding, and Cleanup After Export

SWSD CSV exports use UTF-8 encoding. API responses are standard UTF-8 JSON. Before importing into a target system, handle these common issues:

HTML in text fields: Incident descriptions are stored as rich HTML, often from email-to-ticket conversion. If your destination only supports Markdown or plain text, you must convert during the ETL phase. Importing raw HTML into a plain-text field makes tickets unreadable. Common libraries: Python's html2text for Markdown conversion, BeautifulSoup for plain text extraction.

Date formats: The API returns ISO 8601 timestamps (e.g., 2025-03-15T14:30:00.000-05:00). CSV exports may use locale-specific date formats depending on tenant configuration. Ensure your destination expects UTC or apply timezone offsets during transformation to avoid shifting all your ticket creation dates.

Multi-value custom fields: Exported as comma-separated strings within a single CSV cell, which breaks if any value itself contains commas. In JSON with layout=long, these export as proper arrays.

ID mapping: SolarWinds assigns unique integer IDs to every object. An incident payload lists "requester": {"id": 12345}. You must build a mapping table of SolarWinds IDs to destination IDs so you can re-link requesters, assignees, and CIs during import.

Nested object references: In JSON with layout=long, related objects are fully embedded (an incident's assignee includes the complete user object). In CSV, these flatten to name or email strings, losing the relational ID. Keep raw JSON as your source-of-record extract; treat CSV as an operator-friendly view, not the master archive.

Field naming mismatches: Analytics exports may label fields differently from the UI (e.g., "To Closure" vs. "Service Time to Closure"). The API uses snake_case (created_at) while CSV headers use display names ("Created At"). Validate terminology before mapping to your target schema.

Asset source conflicts: If multiple discovery sources feed the same asset, exported records may contain conflicting values. SolarWinds prioritizes data from different sources internally, but the exported record may not reflect the resolution you expect. (documentation.solarwinds.com)

Re-import constraints: SWSD's CSV import function (Setup → Import) accepts a fixed template schema, not the format produced by CSV export. If you need to round-trip data (export, modify, re-import), you must transform the exported CSV to match the import template. The import template supports incidents, users, hardware, and other assets, but not all object types.

Post-export validation checklist:

1. Record counts match between SWSD UI totals and export file row counts
2. Custom field values present — compare a sample of 10+ records against the UI
3. Date/timestamp formats are consistent and timezone-aware
4. HTML content in descriptions renders correctly or is cleaned
5. Attachment metadata references resolve to downloadable files (test before S3 URLs expire)
6. User references (assignee, requester) resolve to valid user IDs
7. Category/subcategory hierarchies are intact (parent references preserved)
8. CMDB parent-child CI relationships are preserved (recursive traversal complete)
9. No orphaned records (comments referencing deleted incidents)
10. Character encoding verified — no mojibake in international text

Export for Migration vs. Backup vs. Compliance

These three use cases look similar but have different requirements.

Migration Export

Data must be transformed and loaded in dependency order: users and groups first, then CIs and assets, then incidents, problems, and changes (which reference users and CIs). Loading out of order breaks foreign key relationships.

Key requirements:

• ID mapping tables: SWSD internal IDs won't match target platform IDs. Build a table linking swsd_id → target_id for every migrated record. Store these mappings persistently — you will need them for post-migration validation and any follow-up corrections.
• Relationship preservation: Incident→Problem links, CI→Incident associations, and user→group memberships must be rebuilt in the target using mapped IDs.
• Comment and attachment reassociation: Comments must load as children of their parent incidents, preserving timestamps and author attribution.
• Schema transformation: If you are migrating to a platform with a fundamentally different data model — for example, from a complex ITSM model to a flat chat model for a SolarWinds to LiveChat migration — you'll drop entire object types like CMDB. If migrating to ServiceNow, you must map SolarWinds CIs to ServiceNow's specific CMDB classes (e.g., cmdb_ci_server, cmdb_ci_computer).

For a detailed migration walkthrough, see our SolarWinds Service Desk to ServiceNow guide.

Backup Export

You don't need to transform the data, but you must capture the full JSON payload and download all attachments. The pre-signed S3 URLs will expire if your SolarWinds contract lapses.

SolarWinds offers a weekly scheduled CSV backup of product data, but it is not a full-fidelity snapshot — attachments, configurations, and audit trails are excluded. For a true backup, run the API export on a regular schedule and store outputs in versioned, timestamped directories. Version your export scripts alongside the data so you can detect schema drift between runs.

Compliance and Legal Export

GDPR Article 20 (data portability): SWSD provides data in CSV and JSON formats, satisfying the "structured, commonly used and machine-readable format" requirement. SolarWinds confirms customers can request full copies of product data including audit trails in CSV format.

DSAR (Data Subject Access Requests): Use API filters to extract all records associated with a specific user email — incidents they requested, comments they posted, audit entries. The API supports filtering by requester email on most endpoints (e.g., /incidents.json?requester []=email@example.com).

SolarWinds Service Desk is hosted on AWS infrastructure in the US, EU, and Australia with SOC 1/SOC 2 audit reports, PCI DSS Level 1 certification, and ISO 27001 compliance through AWS. HIPAA BAAs are available for healthcare customers.

Contractual note: SolarWinds' Data Processing Addendum states that SolarWinds shall delete or return personal data after termination or after processing services end, unless law requires retention. Do not wait until the last week of a contract to test your export path — run a complete test extraction at least 30 days before contract end to identify and resolve access issues. (solarwinds.com)

How Portable Is SolarWinds Service Desk Data?

Portability rating: Mostly Portable — with significant caveats.

• ~80% of your data (incidents, problems, changes, assets, users, KB articles, CMDB, contracts) exports cleanly via the API in structured JSON.
• ~10% requires extra engineering (attachments need per-record downloads; comments need per-incident API calls; CMDB relationship trees need recursive traversal; inline images need URL rewriting).
• ~10% is not exportable (automation rules, SLA policies, service catalog workflows, notification configurations, dashboard layouts, Task Management v2).

The non-exportable 10% represents your operational configuration — the business logic layer. For organizations with complex multi-tier approval workflows, custom service catalog items, and extensive automation rules, rebuilding this layer in a new platform typically takes 2–4 weeks of dedicated configuration work regardless of how fast the data itself moves.

There are no contractual restrictions on exporting your own data. SolarWinds does not lock you in via Terms of Service. The lock-in is practical:

1. Undocumented rate limit specifics — you cannot accurately scope a timeline without empirical testing on your tenant
2. No bulk attachment endpoint — forces N+1 API calls per record with attachments
3. Non-exportable configurations — automation rules, SLA policies, and workflows must be manually documented and rebuilt
4. S3 URL expiry — forces real-time download during extraction, preventing deferred processing

The real switching cost isn't getting the data out — it's transforming the data to fit a new ITSM schema and rebuilding the ITIL relationships between Incidents, Problems, Changes, and Assets.

The undocumented rate limits are the biggest practical barrier. Without reliably published limits, you cannot accurately scope an export project timeline without running empirical tests against your own tenant first. This alone can add 2–3 days to any migration planning phase.

Timeline and Resourcing for a Full Data Export

Realistic time estimates based on dataset size:

Phase breakdown for a medium-sized export (10K–100K records):

The most common underestimate is attachment extraction time. If you have 50,000 incidents with an average of 2 attachments each, that's 100,000 separate file downloads at rate-limited speeds — roughly 28 hours at 1 request/second. Budget accordingly.

When this shifts from export to migration, the technical work concentrates in comments, attachments, custom fields, and relationship ordering — not in the first GET call. Split extraction, validation, and load into separate checkpoints instead of hoping a single dump is enough.

When to Bring In Help

For teams with fewer than 10,000 records and no attachment requirements, self-serve CSV exports work fine. For anything larger — especially migrations where data integrity, relationship preservation, and attachment fidelity matter — the combination of undocumented rate limits, per-record sub-resource extraction, and format transformation adds up fast.

ClonePartner has completed 1,500+ data migrations across ITSM platforms, including SolarWinds Service Desk extractions with full CMDB relationship trees, comment history, and attachments at scale. If you're evaluating portability or planning a move, a 30-minute scoping call can save weeks of trial-and-error against undocumented API constraints.