How to Export Data from Intercom: Methods, API Limits & Transcripts

Intercom gives you several ways to get data out: a CSV dataset export for reporting metadata, a cloud storage export to S3 or Google Cloud Storage for machine-readable JSON, and a REST API where you control everything but eat rate limits. There is no single "export all" button that gives you every object, full transcripts, attachments, and relationships in one clean package.

The defining constraint is transcripts. Intercom's built-in export tools silently drop conversation message content. According to Intercom's own documentation: "Conversation and ticket data exported to S3 will not contain a transcript. To retrieve a transcript, you can either export the conversation directly from the Intercom UI, or use the REST API." There is also no option to download a CSV of all conversation content directly from your workspace. If you need full message histories — which you almost certainly do for a migration or data warehouse load — you need to build or buy something.

This guide covers every export method step by step, what each one actually returns, what it silently omits, and the exact rate limits and pagination constraints you will hit when extracting contacts, conversations, articles, and companies programmatically.

If you are exporting as part of a platform migration, these destination-specific guides cover field mapping: Intercom to Zendesk, Intercom to Help Scout, or Intercom to Freshdesk.

What Data Can You Actually Export from Intercom?

Before choosing a method, you need to know what Intercom considers exportable and where each extraction path falls short.

The split that matters is flat exports vs. relational content exports. CSV gets you rows. Support history lives in nested conversation parts, attachments, notes, ticket state, and company relationships. A CSV that looks complete on first pass often fails the moment you try to rebuild history in another system.

Method 1: Intercom's Native CSV and Cloud Storage Exports

CSV Dataset Export (Reports > Dataset Export)

This is the quickest way to pull structured metadata out of Intercom without writing code. Go to Reports > Dataset export, select the dataset you want (Conversations, Tickets, etc.), define your date range, optionally filter by attribute, select columns, and preview before exporting.

What you get: A CSV with conversation metadata — IDs, timestamps, assignees, tags, SLA data, custom attributes — or contact/company records with selected fields.

What you don't get: Conversation content. No message bodies, no transcripts, no inline images, no attachments.

For tickets, there are two extra gotchas to know. A ticket that was converted from a conversation can appear with the earlier conversation start date in the CSV. The export also shows all companies associated with the user, even if the UI only shows one company on the ticket. (intercom.com)

Downloading a Single Conversation Transcript

For one-off audits, legal review, or complaint handling, the fastest path is the Inbox. Open the conversation or ticket, click the three-dot menu, and export as text or PDF.

What you do not get is a complete forensic record: transcript files exclude internal notes, assignment history, CC/BCC, images, attachments, GIFs, and embedded apps. Some of these appear only as placeholders in the exported file. (intercom.com)

Teammates need the Can export conversation transcripts permission to download transcript files from the Inbox. (intercom.com)

Contact and Company CSV Export

In the Contacts section, filter the list, open the More menu, and export users, leads, or companies as CSV. Intercom emails the file, and the download link expires after one hour. (intercom.com)

The company data gotcha: The user export currently only includes the name and ID of the most recent company a user was tracked with. No other company data is included. If your users belong to multiple companies over time, you lose all but the latest association. To extract all company relationships, you must bypass the CSV and use the /contacts/{id}/companies API endpoint. (developers.intercom.com)

Archived users also cannot be exported after they have been archived. (intercom.com)

Cloud Storage Export (S3 / Google Cloud Storage)

Intercom can export conversation data as JSON or JSONL to Amazon S3 or Google Cloud Storage. This is the best native option for warehousing or backup at scale.

Setup steps:

1. Navigate to Settings > Data > Imports & exports > Export data and select New data export.
2. Select the Data API version, output format (JSON or JSONL), and toggle whether to include attachments.
3. Configure folder organization: enter a folder name (optional), choose whether to organize into date-named folders, and set whether to skip empty exports.
4. Choose your export type:
   • Historical: A two-year backfill of all conversation data.
   • Periodic: Hourly or daily exports of new and updated conversations.
5. Connect your S3 or GCS bucket.

Practical constraints to know:

• Each batch file contains at most 200 conversations. (intercom.com)
• Periodic files contain the full updated conversation (not a delta), so downstream loaders should upsert by conversation ID and updated timestamp.
• Attachments can be toggled and referenced from the JSON/JSONL data.
• Intercom can write to the bucket but cannot read or delete files.
• You cannot export multiple workspaces to the same bucket. (intercom.com)
• Exported conversation data cannot be imported into a new Intercom workspace. (intercom.com)

The cloud storage export is useful for ongoing backup or feeding a data warehouse. For transcript-grade extraction at scale, you must use the API.

Method 2: Exporting via the REST API

To get complete conversation content — every message, every note, every attachment URL — you need the API.

Conversations API: The N+1 Pattern

The standard approach is: list or search conversations to get IDs, then retrieve each conversation individually for full content.

Step 1: List all conversations

curl -X GET \
  'https://api.intercom.io/conversations?per_page=150' \
  -H 'Authorization: Bearer <YOUR_TOKEN>' \
  -H 'Accept: application/json' \
  -H 'Intercom-Version: 2.11'

The default is 20 conversations per page. You can increase to a maximum of 150 per page using the per_page parameter. Intercom uses cursor-based pagination with a starting_after parameter — you cannot jump to a specific page number. (developers.intercom.com)

For incremental exports, the Search endpoint is better than List because you can filter on updated_at:

# Search conversations updated since the last checkpoint
query = {
    'query': {
        'field': 'updated_at',
        'operator': '>',
        'value': 1710460800
    },
    'pagination': {
        'per_page': 150
    }
}
# POST https://api.intercom.io/conversations/search

Intercom's search language is more limited than a SQL-style filter builder. The docs specify a maximum of 2 nested filter levels and 15 filters inside each AND or OR group. The source.body field is tokenized: searching for "I need support" should use the value support, not need support. (developers.intercom.com)

Step 2: Retrieve full conversation content

The list endpoint returns metadata, not message content. Intercom conversations are broken into conversation parts — each individual message, note, assignment event, or state change. To get these, retrieve each conversation by ID:

curl -X GET \
  'https://api.intercom.io/conversations/{conversation_id}' \
  -H 'Authorization: Bearer <YOUR_TOKEN>' \
  -H 'Accept: application/json' \
  -H 'Intercom-Version: 2.11'

The response includes a conversation_parts array with the full text of every message, note, assignment event, and state change — along with author info, timestamps, and attachment URLs. Append ?display_as=plaintext to get plain-text output instead of HTML.

This is an N+1 pattern: one call to list, then one call per conversation. For 50,000 conversations, that is 50,000+ API calls just for the content retrieval pass. Plan your rate limiting accordingly.

The Data Export API (/export/content/data)

Intercom also provides an asynchronous bulk export endpoint. To create an export job:

curl -X POST \
  'https://api.intercom.io/export/content/data' \
  -H 'Authorization: Bearer <YOUR_TOKEN>' \
  -H 'Content-Type: application/json' \
  -H 'Intercom-Version: 2.11' \
  -d '{
    "created_at_after": 1704067200,
    "created_at_before": 1711929600
  }'

The workflow is asynchronous:

1. Submit the job: POST to /export/content/data with Unix timestamp date ranges.
2. Poll for status: GET /export/content/data/{job_identifier} until the status returns completed.
3. Download the data: Use the provided download URL to retrieve the gzipped CSV.

Key constraints on this endpoint:

• 90-day maximum per request. If you need more than 90 days of history, chain sequential jobs.
• One active job per workspace. Attempting a second concurrent job returns a 429 with "Exceeded rate limit of 1 pending message data export jobs."
• Filters by created_at, not updated_at. If a message was updated yesterday but sent two days ago, you need to set created_at_after before the message was sent. This catches teams who assume "updated in the last 90 days" equals "created in the last 90 days." It does not.
• Jobs expire after two days. Download results promptly after completion.
• Available from API v2.5 onwards.

Because of the created_at filtering behavior, this endpoint is risky as your only incremental mechanism for historical threads that were recently edited. Pair it with the Search endpoint for recently updated conversations.

Exporting Help Center Articles

Intercom does not offer a UI export for articles. To back up or migrate Help Center content, use the Articles API. (intercom.com)

# List all articles (paginated)
curl -X GET \
  'https://api.intercom.io/articles?per_page=50' \
  -H 'Authorization: Bearer <YOUR_TOKEN>' \
  -H 'Accept: application/json'
 
# Retrieve a single article
curl -X GET \
  'https://api.intercom.io/articles/{article_id}' \
  -H 'Authorization: Bearer <YOUR_TOKEN>' \
  -H 'Accept: application/json'

Intercom returns articles in descending updated_at order, which is convenient for incremental exports. Article bodies are HTML, not Markdown, so cleanup is usually required if your target knowledge base uses a different format.

Use the Help Center Collections API at /help_center/collections to preserve your KB folder structure alongside the articles.

Some HTML elements — div, span, form, input, textarea, and script tags — are not supported in article bodies and may be removed or replaced with paragraph tags during export. If your articles contain embedded forms or custom widgets, expect content loss.

Exporting Tickets via API

Intercom exposes ticket data through the Tickets API. The key gotcha: the API uses the internal ticket id, not the Inbox-facing ticket_id (like #12345). This is a common cause of bad joins and 404s during migrations. (developers.intercom.com)

To map ticket schema, list ticket types first, then search or retrieve ticket records. For one-off human exports, the Inbox ticket export can optionally include hidden attributes and internal notes.

Call Transcripts (Intercom Phone)

If you use Intercom Phone, call recordings and line-by-line call transcripts are handled separately from conversation export. Teammates can download recordings and transcripts from the Call Details panel, and the Calls API exposes GET /calls/{id}/transcript. You can retrieve calls by conversation IDs with a maximum of 20 per request. (intercom.com)

Intercom API Rate Limits and Export Constraints

This is where most DIY export scripts break. Intercom's rate limits look generous on paper but have a windowing mechanic that punishes burst traffic.

The 10-Second Window Trap

Private apps have a default rate limit of 10,000 API calls per minute per app and 25,000 API calls per minute per workspace. If a workspace has multiple private apps installed, every one contributes toward the workspace total. (developers.intercom.com)

The real constraint is the windowing. Intercom distributes the per-minute limit evenly into 10-second windows. A 10,000/min limit means roughly 1,666 requests per 10-second period. If your extraction script fires 500 requests in a 2-second burst — common during initial data syncs — you blow past the window limit instantly and start eating 429 responses.

Rate Limit Reference

Handling Rate Limits in Practice

The response headers tell you everything you need:

Read the X-RateLimit-Reset header and calculate the delta. Implement exponential backoff with jitter — not a fixed sleep. A fixed sleep(10) after every batch is wasteful. Read the headers, pace accordingly, and add random jitter to prevent thundering herd problems if you are running multiple workers. (developers.intercom.com)

If your exporter ignores these headers and just sleeps every 60 seconds, you will get bursty 429s for no good reason.

What Cannot Be Exported at All

Some Intercom data simply cannot be extracted through any native method:

• Workflow automations, bots, and Series: Assignment rules, Series automated workflows, bot configurations, and Inbox macros are workspace-specific and non-portable. These require manual re-creation.
• Ongoing conversations: Cannot be migrated between workspaces and must be manually recreated.
• Internal knowledge base articles: No API endpoint exists.
• One-off and ongoing outbound messages: Not fully covered by standard export tools.

This matters whether you are migrating to a new Intercom workspace (e.g., moving from US to EU hosting) or switching platforms entirely.

Third-Party Tools vs. Custom Scripts

You have three paths: native exports (limited), DIY scripts (full control, high effort), and third-party tools (trade-offs in cost and fidelity).

DIY API scripts give you total control over field selection, output format, and destination. You must handle pagination, rate limiting, error recovery, the N+1 conversation pattern, and data stitching yourself. For large workspaces (50K+ conversations), extraction can take hours. You also own the maintenance burden — Intercom API versions change, and breaking changes ship in new versions.

Help Desk Migration is an Intercom-partnered SaaS tool that automates transfer of conversations, contacts, and KB articles to other platforms without code. Good for platform-to-platform migrations with standard field mapping. Less flexible if you need custom transformations or are loading into a data warehouse.

Skyvia is a no-code cloud tool that automates CSV import/export between Intercom and external storage on a schedule. Useful for flat-object periodic syncing. Not purpose-built for helpdesk history reconstruction or complex one-time migrations with relational data.

How ClonePartner Handles High-Volume Intercom Extractions

We have run hundreds of Intercom extractions across workspaces ranging from 5,000 to 500,000+ conversations. The patterns are consistent: teams hit the transcript gap in S3 exports, underestimate the API call volume for conversation parts, and discover the single-company CSV limitation halfway through their migration.

Here is what we do differently:

• Full transcript extraction: We programmatically retrieve every conversation part — messages, notes, assignment events, state changes — with all inline images and attachment URLs preserved. No transcript data is left behind.
• Rate limit management: Our extraction engine reads X-RateLimit-Remaining and X-RateLimit-Reset headers on every response and adjusts throughput in real time. No fixed sleeps, no wasted windows, no 429 cascades.
• Multi-company contact resolution: We resolve all company associations per contact via the API, not just the most recent one the CSV export provides.
• Long-thread handling: We detect conversations that would be truncated by the 500-part retrieve limit and route them through alternative extraction paths.
• Relationship preservation: Tags, custom attributes, conversation-to-contact links, and company hierarchies are extracted as a relational dataset — not flat files that lose context.
• Zero downtime: Your support team keeps working in Intercom throughout the extraction. We run delta syncs to capture conversations that come in during the export window.

Choosing the Right Export Path

Use this decision logic:

• Need a flat list of users, leads, or companies? Use Contacts CSV.
• Need reporting, SLA, or volume analysis? Use Dataset export CSV.
• Need machine-readable support history in bulk? Use cloud storage JSON/JSONL to S3 or GCS.
• Need transcripts, articles, long-thread handling, or cross-object mapping? Use the REST API — or a specialist that works above it.
• Need to move between Intercom regions or workspaces? Export alone is not enough. Intercom states that exported conversation data cannot be imported into a new workspace, so plan the migration path separately.

Intercom can export a lot of data, but it exports it in layers. CSV is not transcripts. Cloud storage JSON is not a human transcript file. The API is powerful but only if you design around rate limits, one-job constraints, the 500-part ceiling, and relationship recovery. Once you know that, the right export method is much easier to choose.