How to Export Data from Thena: Methods, API Limits & Formats

How to Export Data from Thena: Methods, API Limits & Formats

Last verified: August 2025. Thena Platform API v1 endpoints validated against docs.thena.ai; legacy v2/v3 endpoints validated against help.thena.ai. Thena updates quarterly — re-check rate limits and endpoint availability if reading after February 2026.

Thena is an AI-native B2B helpdesk platform built around Slack, Microsoft Teams, email, and web chat. Because it acts as an intelligence layer on top of chat platforms, exporting its data is fundamentally different from exporting from a traditional ticketing system like Zendesk or Freshdesk. As with exporting data from Unthread and other Slack-native tools, much of the underlying conversation data is tied to chat application logic — thread timestamps, Slack user IDs, channel IDs, and message permalinks.

If you're planning a migration, building a data warehouse integration, or backing up your workspace, you won't find a one-click bulk export. This guide covers every extraction method available, their limitations, field-level schemas, and what you can't get out at all.

Thena's Data Model: What You're Actually Exporting

Before touching any export button or writing API calls, understand how Thena structures data. Thena organizes all customer conversations, their issues, and responses under specific accounts. The core entities are:

• Accounts/Organizations — Company-level records with custom fields, contacts, notes, activities, and associated tickets. In Slack-native setups, these map to specific Slack Connect channels.
• Contacts/Users — Individual people linked to accounts, with email, name, and channel identity (a slack_user_id or teams_user_id alongside their email address).
• Tickets — The primary work unit. Tickets come in from Slack, MS Teams, email, web chat, forms, portals, and AI-generated workflows. A single ticket may carry metadata from multiple channels, including Slack thread links, message permalinks, and channel identifiers.
• Requests — The legacy term for tickets in Thena's older data model (the v2/v3 API still uses "requests").
• Comments/Messages — Internal and external thread messages on tickets, categorized as public replies (visible to the customer) or internal notes (visible only to agents).
• Attachments — Files uploaded within chat threads, typically stored via signed S3 URLs that expire after a short window.
• Knowledge Base Articles — Help center content organized by help center and category.
• Tags, SLAs, Forms, Custom Fields — Configuration objects tied to tickets and accounts.

Entity relationships

Understanding which entities reference which is critical for extraction ordering:

Account (1) ──── (many) Contact
Account (1) ──── (many) Ticket
Ticket  (1) ──── (many) Comment
Ticket  (1) ──── (many) Attachment
Contact (1) ──── (many) Ticket  [as requester]
Agent   (1) ──── (many) Ticket  [as assignee]

Extracting tickets before accounts produces orphaned records in any target system. Always extract foundational entities first.

What you cannot export

No API or UI tool will let you export Thena's workflow automations, routing rules, SLA policy definitions, AI agent configurations, integration mappings, or dashboard layouts. If you're migrating platforms, you'll rebuild these from scratch. A full breakdown of exportable vs. non-exportable data is covered below.

Method 1: UI Export — Ticket Dashboard (CSV)

Thena's platform offers a CSV export directly from the ticket dashboard. This is the fastest way to get structured ticket data out.

How to export tickets from Thena's dashboard

1. Navigate to your team's ticket dashboard.
2. Apply any filters, date ranges, or saved views to scope the export.
3. Click the download icon in the top-right corner of the secondary header.
4. The system generates a CSV file named {team-name}-{date}-{time}.csv.

The export respects your current filters — if you've filtered to "Open" tickets only, you'll only get open tickets. There is no documented row limit for the UI export, but exports exceeding approximately 50,000 rows have been observed to time out in practice; scope your filters accordingly.

What's included in the CSV export

The CSV uses UTF-8 with BOM encoding and standardized YYYY-MM-DD HH:mm:ss timestamps — good for Excel and Google Sheets compatibility.

What's missing from the CSV

• Full conversation threads — You get the ticket description, not the back-and-forth messages
• Attachments — Neither inline message attachments nor file upload custom fields
• Internal notes/comments — Agent-to-agent discussion is not exported
• Slack thread links — Not included in the newer ticket CSV (though they were in the legacy request export)
• Related ticket links — Cross-ticket associations are lost
• Relational structure — Multi-contact accounts are flattened, making it difficult to reconstruct the account hierarchy in a target system

Method 2: UI Export — Legacy Request Export (XLSX/JSON)

You can export the entire set of requests from your Thena platform in two formats: XLSX or JSON. This is the older export path available at app.thena.ai under the Customer Support tab.

Steps

1. Go to the Requests section within the Customer Support tab.
2. Select either 'Filtered requests in view' or 'All requests in time frame'.
3. Choose your preferred format from the dropdown menu: JSON or XLSX.
4. Click the download icon to generate and download the file.

Fields in the legacy export

The legacy request export includes fields the newer CSV export does not:

• Request ID, Installation Name, Workspace Name
• Slack Channel, Slack Thread Link — direct links back to the source conversation
• Sentiment, Urgency — AI-generated classification
• AI Tags — auto-generated topic tags
• External Ticket ID, Ticket Connector Name, Ticket Link — references to Zendesk, Jira, or Linear tickets
• CRM Data — synced HubSpot or Salesforce fields
• Merged Requests — references to any merged request IDs

Method 3: Analytics Export

You can export data from any analytics tab by clicking on the download icon in the upper-right corner. The platform is divided into three main tabs: Requests, Accounts, and Workforce. These exports give you aggregate metrics — request volume over time, account-level SLA performance, agent workload distribution — not individual ticket records. Useful for reporting, not for migration.

Method 4: Thena Platform API (Full-Fidelity Extraction)

For complete data extraction, the API is the only path. All APIs require authentication using an x-api-key header. API keys are tied to individual users and can be generated from Dashboard → Organization Settings → Security and Access.

API key scoping

API keys inherit the permissions of the user who generated them. A key generated by a non-admin user will return only data that user has access to — typically tickets assigned to them or their team, not the full workspace. For a complete export, generate the API key from an admin account with full workspace visibility.

API architecture

The API suite is organized into distinct sections:

Rate limits

Standard tier: 60 requests per minute, enforced simultaneously per user, per org, and per IP. Enterprise tier: custom limits based on plan.

Critical for parallel extraction: The rate limit applies to all three dimensions simultaneously. Running 4 parallel workers from the same server with the same API key does not give you 240 requests/minute — it gives you 60, shared across all workers. If you distribute across multiple IPs, the per-IP limit still caps each machine at 60. The binding constraint is the per-org limit.

Rate limit headers are returned on every response:

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 58
X-RateLimit-Reset: 1722873600
X-RateLimit-IP: 203.0.113.42
X-RateLimit-UserID: usr_abc123
X-RateLimit-OrgID: org_xyz789
X-RateLimit-Path: /v1/tickets

If you exceed your rate limit, you will receive a 429 Too Many Requests error. For production deployments, implement retry logic with exponential backoff using the X-RateLimit-Reset timestamp.

429 response body example:

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests. Retry after 1722873600.",
  "retry_after": 1722873600
}

At 60 requests/minute, extracting 10,000 tickets with their comments, contacts, and account data requires careful batching. Each ticket typically needs 2–3 follow-up API calls for comments, attachments, and account details. Expect 3–6 hours for a mid-size dataset (10,000 tickets), significantly more for larger workspaces.

Ticket API response schema

Understanding the actual ticket object structure is essential for planning your transformation step. A representative ticket object from the Platform API:

{
  "id": "tkt_01H8XYZABC123",
  "title": "Cannot access dashboard after SSO change",
  "description": "User reports 403 error when logging in via Okta...",
  "status": "open",
  "priority": "high",
  "type": "bug",
  "source": "slack",
  "created_at": "2025-07-15T09:23:11Z",
  "updated_at": "2025-07-18T14:05:44Z",
  "closed_at": null,
  "due_date": "2025-07-17T09:23:11Z",
  "assignee": {
    "id": "usr_agent_789",
    "name": "Sarah Chen",
    "email": "sarah@yourcompany.com"
  },
  "requester": {
    "id": "usr_contact_456",
    "name": "Marcus Webb",
    "email": "marcus@customer.com",
    "slack_user_id": "U04ABCDEF12"
  },
  "account": {
    "id": "acc_org_321",
    "name": "Acme Corp",
    "slack_channel_id": "C05XYZGHIJK"
  },
  "tags": ["sso", "authentication", "enterprise"],
  "custom_fields": {
    "product_area": "Auth & Access",
    "affected_users": "12",
    "escalation_tier": "T2"
  },
  "sla": {
    "first_response_status": "met",
    "resolution_status": "breached",
    "first_response_due": "2025-07-15T11:23:11Z",
    "resolution_due": "2025-07-17T09:23:11Z"
  },
  "is_escalated": true,
  "is_private": false,
  "csat_rating": null,
  "csat_comment": null,
  "slack_thread_link": "https://yourworkspace.slack.com/archives/C05XYZGHIJK/p1721037791000200",
  "merged_into": null
}

Key implementation notes for this schema:

• closed_at is null for open tickets; always check before assuming presence
• slack_user_id on the requester is your cross-reference for Slack workspace export stitching
• custom_fields is a flat key-value map; keys are your team's configured field slugs
• slack_thread_link is a permalink, not message content — the thread text itself is not stored in Thena

Comment object schema

Each comment retrieved via the comments endpoint:

{
  "id": "cmt_01H9ABCDEF456",
  "ticket_id": "tkt_01H8XYZABC123",
  "body": "Hi Marcus, we've identified the issue. Your Okta integration needs to be reconfigured with the new SSO provider URL.",
  "body_format": "markdown",
  "type": "public_reply",
  "author": {
    "id": "usr_agent_789",
    "name": "Sarah Chen",
    "email": "sarah@yourcompany.com"
  },
  "created_at": "2025-07-15T10:45:22Z",
  "attachments": [
    {
      "id": "att_01HABC123XYZ",
      "filename": "sso-config-guide.pdf",
      "url": "https://thena-attachments.s3.amazonaws.com/signed/...",
      "url_expires_at": "2025-07-15T11:45:22Z",
      "size_bytes": 245680,
      "content_type": "application/pdf"
    }
  ]
}

type values: public_reply (visible to customer) or internal_note (agents only).

Pagination parameters

All list endpoints share the same pagination model:

Response envelope:

{
  "data": [...],
  "meta": {
    "total": 47832,
    "page": 1,
    "per_page": 100,
    "total_pages": 479
  }
}

Detect the last page when page > total_pages or when data is an empty array. The meta.total field is your ground truth for count parity validation.

The legacy v3 endpoint uses cursor-based pagination instead — pass data.next_cursor as a query parameter to fetch subsequent pages. Stop when next_cursor is null or absent.

Deleted and archived record behavior

By default, the /v1/tickets endpoint returns only active (non-deleted) tickets. To retrieve soft-deleted records, append include_deleted=true to your query. Archived tickets are included in standard results by default but can be filtered using status=archived. Always include include_deleted=true in migration exports to avoid silently missing records.

Key extraction endpoints

# Get all tickets (max 100 per page)
curl -X GET "https://platform.thena.ai/v1/tickets?per_page=100&page=1&include_deleted=true" \
  -H "x-api-key: YOUR_API_KEY"
 
# Get comments for a specific ticket
curl -X GET "https://platform.thena.ai/v1/tickets/tkt_01H8XYZABC123/comments?per_page=100" \
  -H "x-api-key: YOUR_API_KEY"
 
# Get all accounts
curl -X GET "https://platform.thena.ai/v1/accounts?per_page=100&page=1" \
  -H "x-api-key: YOUR_API_KEY"
 
# Legacy: Get all requests (deprecated but still functional)
curl -X GET "https://bolt.thena.ai/v3/requests?limit=100" \
  -H "x-api-key: YOUR_API_KEY"

Search API for bulk extraction

The Search API provides powerful, flexible search capabilities across your core business data — tickets, accounts, and comments — using a unified, Typesense-powered interface.

The Search API is often better than list endpoints for large exports because it supports:

• Streaming: Thena's search API supports streaming large result sets for improved performance. Add streaming=true as a query parameter. When enabled, the API streams each page of results as a separate JSON object rather than buffering the full response.
• Filtered extraction: Combine multiple filters in filter_by using && for precise targeting (e.g., status:=open&&priority:=high). Supported operators: := (equals), :!= (not equals), :> (greater than), :< (less than), :>=, :<=.
• Field selection: Use include_fields to limit results to only the fields you need — this improves performance and reduces payload size.

# Search all open high-priority tickets with streaming
curl -X GET "https://platform.thena.ai/v1/search/tickets?q=*&filter_by=status:=open&&priority:=high&streaming=true&per_page=100&include_fields=id,title,status,priority,created_at" \
  -H "x-api-key: YOUR_API_KEY"

Step-by-step API extraction order

When building your extraction pipeline, extract data in a specific order to maintain relational integrity.

Step 1: Extract Accounts and Contacts. Start with foundational entities. You can't correctly assign a ticket to a user or account if those records don't exist in your local database yet. Query the Accounts endpoint to pull all account data, including associated Slack channel mappings. Then query Contacts. Pay close attention to identity fields — a contact in Thena will have a chat platform ID (slack_user_id or teams_user_id) alongside their email. Save both. When migrating to a system like Zendesk or Intercom, you'll use the email as the primary key.

Step 2: Extract Ticket Metadata. Paginate through the Tickets endpoint (or use the Search API with streaming), using per_page=100 and include_deleted=true. For each ticket, extract: ticket_id, title/subject, description, status, priority, assignee_id, requester_id, organization_id, timestamps (created_at, updated_at, closed_at), custom fields, and tags. Write to a local database (PostgreSQL works well) or structured JSONL files. Do not hold the full dataset in memory.

Step 3: Extract Conversation Threads. This is the most API-intensive step. For every ticket_id extracted in Step 2, make a separate API call to retrieve comments and messages. If you have 50,000 tickets, you'll make at least 50,000 API calls just for messages. At 60 requests per minute, and factoring in that each request takes ~200ms plus the sleep interval, this step alone takes nearly 14 hours. Plan accordingly — implement checkpointing so a mid-run failure doesn't require starting over. For each message, capture the author_id, body, body_format, timestamp, and type (public_reply vs. internal_note).

Step 4: Download Attachments.

Save files to your own cloud storage (such as an S3 bucket) and rewrite the URL in your extracted data to point to your permanent location. Validate downloaded files by checking that size_bytes matches the actual downloaded file size and that the file is not a 0-byte or HTML error response disguised as a successful download.

Step 5: Transform and Validate. Covered in detail in the sections below.

Extraction script: practical example

Here's a Python script that paginates through tickets using the Search API with error handling, checkpointing, and rate limit compliance:

import requests
import time
import json
import os
import logging
 
logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s")
 
API_KEY = os.environ.get("THENA_API_KEY")  # Never hardcode credentials
BASE_URL = "https://platform.thena.ai/v1"
HEADERS = {"x-api-key": API_KEY}
CHECKPOINT_FILE = "thena_export_checkpoint.json"
 
def load_checkpoint():
    if os.path.exists(CHECKPOINT_FILE):
        with open(CHECKPOINT_FILE) as f:
            return json.load(f)
    return {"last_page": 0, "total_exported": 0}
 
def save_checkpoint(page, total):
    with open(CHECKPOINT_FILE, "w") as f:
        json.dump({"last_page": page, "total_exported": total}, f)
 
def extract_tickets(output_file="thena_tickets.jsonl"):
    checkpoint = load_checkpoint()
    start_page = checkpoint["last_page"] + 1
    total = checkpoint["total_exported"]
 
    with open(output_file, "a") as f:  # append mode to resume safely
        page = start_page
        while True:
            resp = requests.get(
                f"{BASE_URL}/search/tickets",
                headers=HEADERS,
                params={
                    "q": "*",
                    "per_page": 100,
                    "page": page,
                    "include_deleted": "true"
                },
                timeout=30
            )
 
            if resp.status_code == 429:
                reset_ts = int(resp.headers.get("X-RateLimit-Reset", time.time() + 60))
                wait = max(reset_ts - time.time(), 1)
                logging.warning(f"Rate limited on page {page}. Waiting {wait:.0f}s...")
                time.sleep(wait)
                continue
 
            if resp.status_code >= 500:
                logging.error(f"Server error {resp.status_code} on page {page}. Retrying in 30s...")
                time.sleep(30)
                continue
 
            resp.raise_for_status()
            data = resp.json()
            hits = data.get("hits", data.get("data", []))
            meta = data.get("meta", {})
            total_pages = meta.get("total_pages", 1)
 
            if not hits:
                logging.info(f"No more results at page {page}. Export complete.")
                break
 
            for hit in hits:
                f.write(json.dumps(hit) + "\n")
                total += 1
 
            save_checkpoint(page, total)
            logging.info(f"Page {page}/{total_pages} — {total} tickets exported so far")
 
            if page >= total_pages:
                break
 
            page += 1
            time.sleep(1.1)  # 60 req/min = 1 per second; 1.1s adds safety margin
 
    # Clean up checkpoint on successful completion
    if os.path.exists(CHECKPOINT_FILE):
        os.remove(CHECKPOINT_FILE)
    logging.info(f"Export complete: {total} tickets written to {output_file}")
 
extract_tickets()

Method 5: Webhooks for Real-Time Export

Thena's webhook functionality provides a way to stay informed about specific events in real-time, such as request creation or updates. By integrating these webhooks into systems such as data lakes, CRMs, and other applications, you can instantly process and act upon these events.

Webhooks are configured under Configuration → Integration → Webhooks in the Thena dashboard. Supported events:

• Request Created — fires when a new request/ticket is generated
• Request Updated — fires on any status, assignment, or field change

Thena follows a retry mechanism on delivery failure: 1st retry ~10 seconds after initial attempt, 2nd retry ~20 seconds after 1st, 3rd retry ~30 seconds after 2nd, 4th retry ~50 seconds after 3rd, 5th retry ~80 seconds after 4th. After 5 failed retries, the event is dropped — implement an idempotency key on your webhook receiver and log all incoming payloads to a durable store before processing.

Webhooks won't help with historical data extraction — they only capture events going forward. But for continuous sync to a data warehouse or target platform, they're the right tool for ongoing data flow after an initial API backfill.

What You Cannot Export from Thena

Several categories of Thena data have no documented export or API path:

Knowledge base detail: The /v1/help-centers endpoint lists your help centers and categories. Individual articles can be fetched at /v1/articles/{id}. There is no /v1/articles?per_page=100 bulk list endpoint with full content in the response — you must enumerate category IDs first, then fetch articles per category, then fetch each article individually. A full KB export requires 3 levels of nested API calls and may be impractical at scale.

The Hard Part: Transforming Slack and Teams Data

Extracting the data is only half the battle. If you're migrating from Thena to a traditional helpdesk, you'll face data formatting issues rooted in the chat-native origins of the data.

Field mapping to common target systems

This is the most operationally valuable step for migration planning. The table below maps Thena ticket fields to their equivalents in the three most common migration targets:

Status mapping requires explicit logic — Thena's "pending" maps to Zendesk's "pending" semantically, but Freshdesk uses integer codes. Build a lookup table, not a direct string copy.

Priority mapping: Thena uses string labels; Freshdesk uses integers (1=low, 2=medium, 3=high, 4=urgent). Intercom has no native priority field — you must map to a custom attribute or tag.

Converting Slack markdown to HTML

Slack uses a proprietary flavor of Markdown — *bold* instead of **bold**, <@U123456> for user mentions, <#C123456|channel-name> for channel references. Most target helpdesks (Zendesk, Freshdesk, HubSpot) expect HTML.

If you push raw Thena message bodies into a new system, they'll look broken. The critical transformations are:

The <@U123456> user mention lookup is the most failure-prone step: you need to cross-reference the Slack user ID against the contact records extracted in Step 1. If a mention references a Slack user who isn't a Thena contact (e.g., an internal employee who never raised a ticket), the lookup will fail. Build a fallback: if no Thena contact matches the Slack user ID, preserve the raw mention tag in a comment like <!-- unresolved mention: U04ABCDEF12 --> rather than silently dropping it.

Handling thread context

In Slack, conversations are highly nonlinear. Multiple people reply in a thread simultaneously. When flattening this into a traditional ticket's chronological view, context is often lost.

Thena stores permalinks to Slack threads, not full message text. If your team relied heavily on Slack-native support and you need complete conversation history, you must supplement your Thena export with a Slack workspace export and stitch the data together using Slack thread timestamps and channel IDs. The join key is: Thena's slack_thread_link contains the channel ID and thread timestamp (/archives/{channel_id}/p{timestamp}), which maps to Slack export's channel and ts fields.

To mitigate context loss during transformation, prepend the author's name and timestamp to the top of every message body during the transformation phase — this ensures clarity in the target system regardless of how that system renders conversation history.

QA and Validation

Never assume an API extraction ran perfectly. Network blips, rate limit spikes, and server errors produce silent data gaps.

After your extraction completes, run these validation checks:

1. Count parity: Query GET /v1/tickets?per_page=1 and check meta.total in the response. Does this number match the total records in your local database?
2. Orphaned records: Are there comments or attachments tied to a ticket_id that doesn't exist in your database? This indicates a pagination gap.
3. Null requester handling: Some tickets (system-generated or AI-triggered) may have a null requester field. Your schema must accommodate this without crashing the import.
4. Attachment integrity: For a random sample of 100 downloaded attachments, verify that the file's actual byte size matches size_bytes from the API response. A mismatch indicates a failed download that produced a partial or error-page file.
5. Status completeness: Confirm your extracted dataset includes tickets in all statuses (open, closed, pending, archived). If archived or deleted tickets are missing, you likely forgot include_deleted=true.

Data Portability Assessment

What ports well: Ticket metadata, customer/account records, contact information, CSAT scores, tags, and SLA compliance data. These map cleanly to most target helpdesks (Zendesk, Freshdesk, Intercom, HubSpot Service Hub) using the field mapping table above.

What doesn't port well: Slack thread context. Thena's deep Slack integration means a significant amount of conversation history lives in Slack threads, referenced by permalink in Thena but not stored as first-class message data in the export. This is the single largest fidelity loss in any Thena migration.

What requires manual rebuild: Workflow automations, routing rules, SLA policy definitions, AI agent configurations, and integration mappings. These are platform-specific configurations with no portable format. Budget 1–3 weeks of configuration time to recreate these in a target platform, depending on workflow complexity.

Planning Your Thena Export: Decision Framework

For migrations involving more than 5,000 tickets, a CSV-based approach will fall short. See our guide on using CSVs for SaaS data migrations for a detailed breakdown of where flat-file exports break down.

Common Failure Modes and How to Handle Them

The following failure patterns appear consistently in production Thena extraction runs:

For related planning, see our Thena to Podium Migration Guide and Thena to SurveySparrow Migration Guide.