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

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

Like Help Scout and Unthread, Helpshift does not have a one-click "Export Everything" feature. The dashboard-level exports cover analytics metrics only — issue volume, CSAT scores, resolution times — delivered as CSV. They explicitly exclude message bodies, conversation threads, and attachments.

If you need the actual content of your support conversations, end-user profiles, FAQ articles, or Custom Issue Fields (CIFs), you must use the Helpshift REST API or the User Hub Bulk APIs. There is no middle ground.

This guide covers every extraction method available in Helpshift, what each method actually returns, the exact pagination and query limits you will hit, and how to structure a migration-ready export. All technical details were verified against Helpshift REST API v1 and the User Hub Bulk API documentation. Last reviewed: Q2 2025.

What Data Can You Export from Helpshift?

Helpshift's data model centers on Issues (tickets), Messages (conversation threads), FAQs, FAQ Sections, Apps, Users (end users), and Agents. Operational metadata includes Tags, Custom Issue Fields (CIFs), CSAT feedback, and device/platform metadata — a reflection of Helpshift's mobile-first, in-app support model.

The REST API exposes read access to all core objects. Here is what each export method actually gets you:

The gap between what the dashboard gives you and what you need for a migration is significant. Everything below the line of "Issues (metadata)" in the table above requires the REST API.

Method 1: Power BI Dashboard Export

Helpshift integrates with Microsoft Power BI to surface analytics dashboards — Support Analytics, Agent Analytics, FAQ Analytics, and Bots Analytics. You can export any visualization from these dashboards as a CSV file.

Navigate to your Helpshift Power BI dashboard, click the ellipsis (three dots) on any visualization, and select "Export data." The file downloads as .csv.

The Power BI export is scoped to whatever date range and filters are active on the dashboard page. It gives you aggregate metrics: issue counts, CSAT scores, response times, resolution rates. It is good for auditing and operational reporting. It is useless for data migration.

Method 2: Helpshift Analytics CSV Export

The Helpshift Analytics page (separate from Power BI) has its own export function. Navigate to the Analytics page, select the report tab, and click the export icon in the top-right corner.

This exports the metrics visible on that specific page as CSV, constrained to the selected date range. Like Power BI, this covers metrics only — not conversation content, not message bodies, not attachments.

Both dashboard export methods are appropriate for operational reporting. Neither is a migration tool.

Method 3: The Helpshift REST API (The Real Export)

The REST API is the only way to get full issue data — including message bodies, author details, tags, CIFs, CSAT feedback, and device metadata — out of Helpshift.

Authentication

Helpshift uses API key-based authentication via HTTP Basic Auth. The API key is the username; the password field is left empty. The API does not currently support OAuth 2.0 or token-based authentication — API keys do not expire on a schedule, but they can be revoked manually.

curl -u "YOUR_API_KEY:" \
  "https://api.helpshift.com/v1/YOUR_DOMAIN/issues?page-size=100"

You manage API keys from Settings → APIs in the Helpshift Dashboard. You can create multiple keys with different access levels (read-only vs. read-write). Helpshift logs which admin views each key.

Core Endpoints for Export

The Issues API: What You Actually Get Back

Unlike some platforms that require a separate API call per ticket to fetch messages, Helpshift embeds the full messages array directly inside each Issue object. This reduces total API call volume but produces large JSON payloads — expect 5–20 KB per issue depending on message count and attachment metadata.

Each issue response includes:

• id — Helpshift issue ID
• title — Issue title / first message subject
• messages [] — Array of all messages, each with body (HTML), created_at (Unix ms), and author object (name, id, emails)
• tags [] — Applied tags
• state_data — Current state (new, new-for-agent, agent-replied, resolved, rejected) and changed_at timestamp
• assignee_name / assignee_id — Assigned agent
• app_id — Which Helpshift app this issue belongs to
• author_name / author_email — Issue creator
• created_at — Creation timestamp in Unix milliseconds
• updated_at — Last modification timestamp in Unix milliseconds (useful for delta sync)

Optional fields (via the includes parameter — not returned by default):

• meta — Device metadata: OS version, device model, app version, battery level, carrier, network type, language
• custom_fields — Custom Issue Fields (CIFs)
• feedback_rating / feedback_comment — CSAT data

{
  "issues": [
    {
      "id": "1234567890",
      "title": "App crashing on startup",
      "status": "resolved",
      "created_at": 1672531200000,
      "updated_at": 1672617600000,
      "custom_fields": {
        "subscription_tier": {
          "type": "singleline",
          "value": "premium"
        }
      },
      "messages": [
        {
          "id": "msg_1",
          "body": "<p>The app crashes when I open the settings menu.</p>",
          "author": {
            "name": "Jane Doe",
            "role": "end_user"
          },
          "created_at": 1672531200000,
          "attachments": []
        }
      ]
    }
  ]
}

Note that body is returned as HTML, not plain text. If your target platform requires plain text or Markdown, you must run a conversion step during transformation.

# Fetch issues with metadata, custom fields, and CSAT feedback
curl -u "YOUR_API_KEY:" \
  "https://api.helpshift.com/v1/YOUR_DOMAIN/issues?includes=%5B%22meta%22%2C%22custom_fields%22%2C%22feedback%22%5D&page-size=1000"

Pagination Rules and the 50,000 Record Ceiling

This is where most Helpshift exports hit a wall.

Helpshift's pagination works like this:

• Default page size: 100 issues per page
• Maximum page size: 1,000 issues per page (set via page-size parameter)
• Maximum traversable records: The product of page × page-size cannot exceed 50,000

If you set page-size=1000, you can fetch up to page 50 — giving you 50,000 issues total. If your Helpshift instance has more than 50,000 issues, a single unfiltered query cannot retrieve them all.

What happens when you exceed the 50K ceiling? If you request page=51 with page-size=1000, the API returns an HTTP 200 response with an empty issues array — it does not return an error code. This means your script will silently stop at the boundary, with no indication that records were skipped. There is no X-Total-Count header or equivalent to tell you the actual issue count before you start paginating. The only way to detect truncation is to compare your extracted count against an issue count pulled from your Helpshift Analytics dashboard.

How to Export More Than 50,000 Issues

The official workaround is cursor-based pagination using date ranges. Helpshift's developer documentation provides this pattern, which uses created_since as a moving cursor:

1. Set created_since and created_until to define a time window.
2. Set sort-by=creation-time and sort-order=asc.
3. Do not pass page or page-size parameters.
4. Process all issues except the last one in each response.
5. Use the created_at value of the last issue as the new created_since for the next query.
6. Repeat until the API returns an empty issues array.

import requests
import time
import datetime
 
def get_timestamp_in_ms(date_str):
    return str(int(time.mktime(
        datetime.datetime.strptime(date_str, "%d/%m/%Y").timetuple()
    ) * 1e3))
 
start_ts = get_timestamp_in_ms("01/01/2020")
end_ts = get_timestamp_in_ms("01/01/2026")
 
all_issues = []
seen_ids = set()  # Deduplication guard for timestamp collisions
 
while True:
    r = requests.get(
        f"https://api.helpshift.com/v1/YOUR_DOMAIN/issues"
        f"?sort-by=creation-time&sort-order=asc"
        f"&created_since={start_ts}&created_until={end_ts}"
        f"&includes=%5B%22meta%22%2C%22custom_fields%22%2C%22feedback%22%5D",
        auth=("YOUR_API_KEY", "")
    )
    data = r.json()
    issues = data.get("issues", [])
 
    if not issues:
        break
 
    if len(issues) == 1:
        issue = issues[0]
        if issue["id"] not in seen_ids:
            all_issues.append(issue)
            seen_ids.add(issue["id"])
        break
 
    # Process all but the last (it becomes the next cursor)
    for issue in issues[:-1]:
        if issue["id"] not in seen_ids:
            all_issues.append(issue)
            seen_ids.add(issue["id"])
 
    last = issues[-1]
    start_ts = str(last["created_at"])
 
print(f"Exported {len(all_issues)} issues")

Delta Sync with updated_since

The created_since cursor covers historical extraction. For incremental sync — capturing issues that were updated after your initial export — use the updated_since filter instead. This parameter accepts a Unix millisecond timestamp and returns all issues with an updated_at value greater than or equal to the specified time.

# Fetch issues updated after a specific point in time
curl -u "YOUR_API_KEY:" \
  "https://api.helpshift.com/v1/YOUR_DOMAIN/issues?updated_since=1672531200000&sort-by=updated-at&sort-order=asc"

A complete migration pipeline uses created_since cursor pagination for the historical bulk export, then switches to updated_since polling during the cutover window to capture changes made while the bulk export was running.

Filtering Parameters

The Issues API supports several useful filters for targeted exports:

• state — Filter by issue state: new, new-for-agent, agent-replied, resolved, rejected
• created_since / created_until — Unix timestamps in milliseconds
• updated_since — Unix timestamp in milliseconds; returns issues modified after this point
• sort-by — creation-time or updated-at
• sort-order — asc or desc
• feedback-rating — JSON filter object for CSAT scores
• app_id — Filter by specific Helpshift app

Rate Limits

Helpshift does not publish a fixed global rate limit in its public documentation. Rate limits are configured per domain and managed through Settings → APIs in the dashboard. The limit depends on your contract tier and what your account manager has provisioned.

Based on observed behavior across multiple extraction workloads, most Helpshift domains sustain 100–300 requests per minute before returning 429 Too Many Requests. Enterprise domains with dedicated infrastructure tend toward the higher end of this range, but treat these as directional estimates, not guarantees — verify against your own domain before committing to a pipeline design.

When you hit the rate limit, the API returns HTTP 429. The response body typically looks like:

{
  "status": "error",
  "message": "API rate limit exceeded. Please slow down your requests."
}

Check for a Retry-After header in the response — when present, it specifies the number of seconds to wait before retrying. Implement exponential backoff as a fallback when the header is absent:

import time
import requests
 
def fetch_with_backoff(url, auth, max_retries=5):
    retries = 0
    delay = 2  # Start with 2-second delay
 
    while retries < max_retries:
        response = requests.get(url, auth=auth)
 
        if response.status_code == 200:
            return response.json()
 
        if response.status_code == 429:
            retry_after = int(response.headers.get("Retry-After", delay))
            print(f"Rate limited. Waiting {retry_after} seconds...")
            time.sleep(retry_after)
            retries += 1
            delay = min(delay * 2, 60)  # Cap at 60 seconds
        else:
            response.raise_for_status()
 
    raise Exception("Max retries exceeded")

For large-volume exports, add a 1–2 second delay between paginated requests as a preventive measure, even before hitting a 429.

Method 4: User Hub Bulk APIs (End User Profiles)

The User Hub Bulk APIs handle end-user profile data specifically — not issues or FAQs. This is an asynchronous, task-based API designed for importing and exporting user profile records in bulk.

How it works:

1. Call the Create Bulk Action Task API with a task type of export_core_profiles.
2. Receive a Task ID in the response.
3. Poll the Get Task Status API until the status is completed.
4. Retrieve results via the Get Task Results API.

The payload limit is 10,000 profiles per request. For larger user bases, batch your export requests by user ID range or creation date.

This API is useful when you need to export user identity and profile data separately from issues — for example, to pre-populate user records in a target platform before migrating conversation history.

Method 5: Webhooks (Real-Time, Not Bulk)

Helpshift Webhooks push event data to an HTTPS endpoint whenever something happens in your instance — an issue is created, updated, or resolved.

Webhooks are not a bulk export mechanism. They are useful for:

• Building a real-time mirror of Helpshift events into a data warehouse
• Triggering downstream workflows (Slack notifications, JIRA ticket creation)
• Incremental sync after a bulk historical export via the updated_since filter

You configure webhooks from Settings → APIs → Webhooks in the dashboard. Each webhook specifies a target URL, authentication method, app scope, and event types.

The most effective migration pattern is: REST API with created_since cursor for historical bulk extraction, then updated_since polling or Webhooks for delta sync during the cutover window. This minimizes data loss during transition without requiring continuous webhook uptime throughout the bulk export phase.

Method 6: GDPR Data Portability Request

Under GDPR Article 20, Helpshift supports data portability requests. You can use the REST API to request a copy of issue or end-user data. This is designed for individual user requests ("give me all data you have about user X"), not bulk platform exports.

Helpshift also exposes a Redaction API (/redaction) for GDPR Article 17 (Right to Be Forgotten) compliance. Redaction requests are processed in weekly batches.

This method is for compliance workflows, not migration.

Attachment Handling

Attachments are not base64-encoded in the API response. They are stored on Helpshift's infrastructure (AWS S3), and the API returns a pre-signed, time-limited URL inside the attachments array of each message object.

To handle attachments correctly during a migration:

1. Parse the messages array for any objects where attachments is not empty.
2. Execute an HTTP GET request to the provided pre-signed URL immediately.
3. Save the binary file to your own secure, permanent cloud storage (e.g., an S3 bucket you control).
4. Rewrite the attachment URL in your JSON payload to point to your permanent storage location before mapping the data to your target platform.

Attachment downloads should be part of the primary export pipeline, not a post-processing step. Running attachment downloads separately — after JSON extraction is complete — risks URL expiration.

Extracting FAQs and Knowledge Base Content

Helpshift's Knowledge Base is structured around Sections and FAQs. Use GET /v1/{domain}/faqs for articles and GET /v1/{domain}/sections for the section hierarchy.

FAQ API response details to be aware of:

• Body format: FAQ body content is returned as HTML. If your target platform requires Markdown (Zendesk Guide, Help Scout Docs), run the payload through an HTML-to-Markdown converter (Turndown for Node.js, python-markdownify for Python) before importing.
• Localization: Helpshift FAQs are tied to specific app localizations. Each FAQ object includes a language attribute. If you extract FAQs without filtering by language, you will retrieve all localized variants — Spanish, French, and English articles will all appear in the same response. Filter by language or group by it explicitly during transformation.
• Images in FAQ bodies: Inline images in FAQ articles are typically embedded as absolute URLs pointing to Helpshift's CDN. These URLs may become inaccessible after your contract ends. Treat FAQ images with the same urgency as issue attachments — download and re-host them before migration.
• Character encoding: FAQ body content is UTF-8. Watch for HTML entities (&, <, etc.) that need unescaping before inserting into a target platform that expects raw Unicode.

Device Metadata and Custom Issue Fields

Because Helpshift integrates into mobile apps via SDKs—a common reason teams migrate to Helpshift—issues often contain rich device metadata in the meta object. Common fields include app_version, os_version, device_model, battery_level, carrier, network_type, and language.

If you are migrating to Zendesk, Kustomer, or Freshdesk, these fields do not have native equivalents. You must pre-create custom fields in your target platform and map these exact string values during the ETL process. Failure to map device metadata means your engineering team loses critical debugging context for historical tickets.

CIF type casting: Helpshift allows CIFs to be singleline, multiline, number, checkbox, or date types. Two important gotchas:

1. Stringified booleans: The API sometimes returns checkbox type values as the string "true" rather than the boolean true. If your target platform enforces strict type validation on custom fields, imports will fail silently or throw validation errors. Cast explicitly during transformation.
2. Date format: CIF date values are returned as Unix millisecond timestamps, not ISO 8601 strings. Most target platforms expect ISO 8601 (2023-01-01T00:00:00Z). Convert during transformation.

What You Cannot Export from Helpshift

Several categories of Helpshift configuration data are not accessible via any API or export method:

• Automation rules and workflows — Must be manually recreated in the target platform
• Bot configurations (QuickSearch Bot, Custom Bots) — No export path
• Smart Views — Filter/view configurations are not exportable
• Queue assignments and routing rules — Must be rebuilt
• Agent permissions and roles — Not exportable; rebuild manually
• Dashboard layouts and Power BI report configurations — Tied to your Helpshift instance
• Engagement campaign configurations — No export API
• Deleted or purged issues — The REST API only surfaces currently active data. Issues purged under your data retention policy are unrecoverable.
• Spam-rejected issues — Issues in rejected state may be excluded from standard issue list queries depending on filter configuration. Test your filter parameters against a known-rejected issue before assuming completeness.

If you are migrating to another platform, budget time for manually reconstructing automation and configuration. For a mid-size Helpshift instance, expect 4–8 hours of manual configuration work on top of the data migration itself.

Common Export Pitfalls

When building a Helpshift extraction pipeline, teams consistently encounter the same failure modes:

1. Forgetting the includes parameter. By default, the Issues API does not return meta, custom_fields, or CSAT data. A full export without includes gives you issues and messages but omits everything else. You must re-crawl the entire dataset to recover it.

2. Silent truncation at the 50K ceiling. Naive pagination with page and page-size parameters maxes out at 50,000 issues. The API returns an HTTP 200 with an empty issues array — no error, no warning. Without cursor logic, you will not know you stopped early unless you cross-reference against your dashboard totals.

3. Missing the updated_since filter for delta sync. The created_since cursor captures historical issues. It does not capture issues that existed before your extraction window but were updated during it. Use updated_since for the delta pass.

4. Not accounting for live changes during export. Helpshift is a live system. Issues can be created, updated, or resolved while you are paginating through results. Sort ascending by creation-time and run a updated_since delta pass after the initial bulk export.

5. Treating Power BI exports as data exports. The Power BI CSV explicitly does not contain message body text. It cannot be used to reconstruct conversation history.

6. Letting attachment URLs expire. Pre-signed S3 URLs have short TTLs. Download attachments within the same pipeline pass that fetches the JSON. Do not treat them as a separate phase.

7. Bot message authorship. Messages sent by Helpshift's QuickSearch Bot or Custom Bots have author.role set to something other than agent or end_user. If your target platform requires every message to be linked to a valid Agent ID, create a "Helpshift Bot" placeholder agent in the target system and map all bot-authored messages to that ID.

8. FAQ image and localization handling. Extracting FAQ HTML without accounting for inline CDN images and language variants will result in broken image links and duplicate articles in the target system.

9. CIF type casting failures. Stringified booleans and Unix millisecond date values will cause silent import failures or validation errors on strictly-typed target platforms. Validate and cast every CIF field during transformation.

Building a Migration-Ready Export

A migration-ready Helpshift export is not a raw JSON dump. It is a structured dataset that preserves relational integrity so a target platform can ingest it without manual cleanup. Here is the minimum extraction checklist:

1. Issues with full messages — GET /issues with includes=["meta","custom_fields","feedback"], using cursor-based created_since pagination
2. Delta pass — GET /issues with updated_since set to the start time of your bulk export, to capture updates made during extraction
3. FAQs and sections — GET /faqs and GET /sections, filtered by language; download inline images
4. Agent roster — GET /agents for agent ID → name/email mapping
5. App list — GET /apps for app ID → app name mapping
6. End user profiles — User Hub Bulk API export for user identity data
7. Attachments — Downloaded from pre-signed URLs in message payloads, re-hosted in permanent storage

Once extracted, the transformation layer must address:

• Flatten nested message arrays — Most target platforms (Zendesk, Freshdesk, Intercom) expect conversations and messages as separate objects, not embedded JSON arrays
• Map Helpshift states to target states — new, new-for-agent, agent-replied, resolved, rejected do not map 1:1 to any major platform; define a mapping table explicitly
• Convert Unix millisecond timestamps — Helpshift uses ms-precision Unix timestamps; most platforms expect ISO 8601 (2023-01-01T00:00:00Z)
• Convert HTML message bodies — Helpshift stores message content as HTML; some platforms require plain text or Markdown
• Resolve agent IDs — Helpshift's assignee_id is an internal profile ID that has no meaning in the target system; build an agent email → new ID mapping table
• Cast CIF types — Explicitly convert stringified booleans and millisecond date values before import
• Remap attachment URLs — Replace pre-signed Helpshift URLs with your permanent storage URLs

For teams evaluating their overall approach, the trade-offs between DIY scripts, migration tools, and services are covered in our help desk migration alternatives guide.

Export Time Estimates

Based on migration workloads across multiple Helpshift instances:

These estimates include extraction with full includes and attachment downloads. API-only extraction without attachments is roughly 3–5x faster. Attachment volume is the primary driver of variance at all instance sizes.

When to DIY vs. When to Get Help

DIY makes sense when:

• You have fewer than 10,000 issues
• Attachment migration is not required
• Your target platform has a well-documented import API
• You have a developer available for 1–2 weeks

Consider a migration service when:

• You are over 50,000 issues and need guaranteed completeness
• You need to preserve Custom Issue Fields and CSAT data with type integrity in the target
• You are migrating to a platform with complex import requirements (Zendesk, Salesforce Service Cloud)
• Downtime is unacceptable — you need extraction, transformation, and load to happen in a coordinated cutover window

For a mid-sized dataset (50,000 to 100,000 issues), expect 80–120 engineer-hours to build, test, and execute extraction and transformation scripts. The Helpshift API is well-structured, but the silent 50K truncation, missing includes fields, and CIF type casting issues catch most teams on the first extraction attempt.