How to Export Data from Front: Methods, API Limits & Gaps

How to Export Data from Front: Methods, API Limits & Gaps

Front does not offer a single self-service bulk export. If you want to get your data out — conversations, messages, contacts, analytics, attachments — you are working with a patchwork of methods: a support-assisted account export, the Core API, UI-based analytics exports, and contacts CSV downloads. Each method covers different data, has different limitations, and none of them alone gives you everything.

Part of the problem is architectural. Traditional helpdesks like Zendesk or Freshdesk store support interactions as discrete ticket objects. Front stores them as a web of conversations, messages, internal comments, and events — there is no "ticket" concept. This model is powerful for collaboration but creates high friction when you need to extract data for compliance, analytics, or a full migration to another platform.

This guide maps every extraction path available in Front as of mid-2026, including exact API rate limits, endpoint-level behavior, what each method includes and excludes, and the portability gaps that catch teams off guard during migrations.

If you are planning a move away from Front, pair this with our Front Migration Checklist for the full picture. For a deep dive on Front's architecture, see Mastering Front: A Technical Deep Dive.

The Four Ways to Export Data from Front

Front's export story is split across four distinct mechanisms. No single one covers all data types. Here is the quick comparison before we go deep on each:

Method 1: Support-Assisted Account Data Export

What it is: A manual export request you submit to Front's Support team. They process it and send you the files.

You will need to contact Front's Support team in order to export your team's Front account data. You cannot do this on your own in the app at this time.

How to request it

Contact Front's Support team with the line "Account data export request for {Customer name}." If you also need a knowledge base export, include the names of the knowledge bases in your request. You must have company admin permissions for the account for which you're requesting an export.

What you get

When you request an account data export, Front will provide conversations, messages, and discussions in your shared inboxes. The account data export will be structured in a set of folders by inbox in CSV files. If you need message files in EML format, you can request that explicitly. Each file is not necessarily an inbox, and will represent about 700MB of data, alphabetically ordered.

For large accounts with multi-year histories, this typically produces multiple 700MB files. There is no built-in index that maps files to inboxes — you must reconcile file contents against inbox names manually. If you're using Front's knowledge base, they'll provide separate files with your content.

What you don't get

This is where teams get burned:

• Front will not include attachments, comments, conversations, or discussions from individual inboxes or contact data.
• They will not export message templates and tags.

That is a significant list of exclusions. If you rely on internal comments for context, use individual inboxes for personal email, or need tag data for downstream routing, the support export will not cover you. All of these require the API.

Timeline

Front will acknowledge your data export request within 72 hours and let you know that they have started processing the export. Actual delivery depends on data volume. Accounts with multi-year histories and high conversation counts typically take 3–7 business days for full delivery.

Method 2: Front Core API — Full Programmatic Extraction

The Core API is the most complete extraction path. It allows you to read, create, update, and delete a wide range of data across Front's various entities, from Contacts to Comments to Tags. If your use case involves programmatic syncing, export, or modification of Front data, the Core API is likely what you're looking for.

Authentication: API Tokens vs. OAuth

Front supports two authentication methods: API tokens and OAuth 2.0. For one-off extractions and migration scripts, the choice has meaningful rate limit implications.

API tokens are workspace-scoped credentials generated under Settings → Developers → API Tokens. They operate under your plan's standard rate limit (see table below). Grant read scopes for conversations, contacts, tags, custom fields, inboxes, teammates, and analytics. If you need private inbox data — common during full migrations — you must also enable the Private resources scope, which requires explicit permission from inbox owners.

OAuth 2.0 operates under a separate rate limit pool. API requests made by a partner integration on behalf of a company via OAuth have a separate rate limit of 120 rpm, enforced on a per-company basis. This means that API requests made by integrations installed by a customer do not count against the customer's rate limit (the only exception is the Zapier integration).

This separation is a meaningful optimization lever: if you register your extraction script as an OAuth application, its 120 rpm pool does not consume your standard API token quota. For accounts running automated integrations alongside a migration extraction, this avoids rate limit contention. The OAuth flow uses standard Authorization Code grant with Bearer token authentication; tokens expire and must be refreshed using the refresh_token grant.

API rate limits by plan

By default, Front's API rate limit starts at 50 requests per minute and varies depending on your plan. Rate limits are enforced on a per-company basis rather than a per-token basis.

Rate limit increases beyond the default limits require the Professional plan or higher. Getting more capacity costs an extra $200 per month for every 100 requests per minute you add.

Burst and proportional limits

The per-minute number is not the whole story. Front also enforces burst limits and proportional limits on specific endpoints:

• Burst allowance: Equal to half your plan's standard rate limit. If you momentarily exceed your limit, the burst buffer lets you continue — but once exhausted, it takes 10 minutes to fully replenish. On a Starter plan, this means a burst of 25 additional requests before the hard block.
• Conversation search (GET /conversations/search/{query}): Subject to proportional rate limiting at 40% of your global rate limit. On a Starter plan (50 rpm), that means a maximum of 20 search requests per minute.
• Analytics endpoints (POST /analytics/exports, POST /analytics/reports): Tier 1 — limited to 1 request per second.
• Message and conversation updates: Tier 2 — limited to 5 requests per resource per second.
• Events endpoint (GET /events): Returns only 15 items per page, making it slow for deep backfill or change capture at scale.

Key endpoints for data extraction

Critical architectural detail: The conversation object itself does not contain actual email bodies or chat text. It contains only metadata — subject, status, assignee, tags, and a reference to the messages endpoint. You must call GET /conversations/{id}/messages separately to retrieve message content. Front stores message bodies in both plaintext and HTML formats. Always extract the HTML version if you need to preserve inline formatting, tables, and hyperlinked text — the plaintext version strips these.

Estimating your extraction scope before you start

Before writing a single line of extraction code, estimate your total conversation count using the GET /conversations endpoint response metadata. The response body includes a _pagination object; the absence of a next cursor after requesting with limit=1 tells you nothing about total count. Instead, use the analytics dashboard (Reports → Overview → Total conversations) to get an approximate count, or query POST /analytics/reports for a count breakdown by inbox and date range. This scoping exercise takes 30 minutes and prevents you from discovering mid-extraction that your 10,000-conversation estimate was actually 80,000.

Pagination

Front uses cursor pagination. Pass limit (default 50, max 100) and then follow _pagination.next — a full URL with the page token baked in — until it returns null.

This means exporting 100,000 conversations requires a minimum of 1,000 paginated API calls just for the conversation list — before you fetch messages, comments, or attachments for each one.

{
  "_pagination": {
    "prev": null,
    "next": "https://api2.frontapp.com/conversations?page_token=eyJhbGci..."
  },
  "_results": [
    ...
  ]
}

Do not attempt to parse or modify the page_token parameter. It is an opaque string — pass the full _pagination.next URL directly into your next GET request.

What the API can export that the support export cannot

• Internal comments on conversations
• Attachments (downloaded per-message via authenticated requests)
• Tags and tag-to-conversation associations
• Custom fields on contacts, conversations, and accounts
• Contact data including handles, lists, and custom fields
• Individual inbox conversations (if the API token has the Private resources scope)

What the API cannot export

Even the API has blind spots:

• Rules and automations — no endpoint to read rule definitions
• Message templates — not exposed via the Core API
• Drafts — listable per conversation, but not bulk-exported easily
• Knowledge base content — separate from the Core API; request via support
• Analytics-computed metrics (response times, SLA performance data) — available only via the analytics export endpoints, not from conversation objects
• SLA policies — configuration is not exportable
• Signatures — must be manually recreated

Sample export application and open-source tools

Front provides an official sample export application on their Developer Portal. For each conversation that matches, the export application will generate JSON files that contain the conversation details, including the details of the messages, comments, and attachments of the conversation (depending on which options you enabled in the configuration). The sample app is written in TypeScript/Node.js and covers pagination handling, rate limiting, and attachment downloads.

The open-source front-export tool on GitHub also helps you export your messages including attachments to a JSON file and to .eml files which you can import to apps like Outlook or Thunderbird. These tools are useful for small-scale backups but lack production-grade error handling and the ability to process accounts with hundreds of thousands of conversations.

Method 3: Analytics CSV Export

Front's analytics dashboard lets you export message-level and event-level data as CSV files directly from the UI.

You can export a CSV file with the raw data of your view by clicking the three-dot menu on the top right and selecting Export data.

Front offers two main types of analytics CSV exports: a Messages export and a Full events export.

The Messages export includes one line per message with fields: message ID, conversation ID, direction (inbound/outbound), status, inbox name, message date, reaction time, total reply time, assignee, tags, and autoreply flag.

The Full events export captures granular event-level data including assignment changes, status transitions, tag additions and removals, and reply events. This is the closest Front gets to a change log for conversation activity.

After 30 days, the exports you generated will be deleted from the exports list in the report. Download promptly after generation.

You can also request analytics exports programmatically via POST /analytics/exports or POST /analytics/reports. These endpoints are rate-limited to 1 request per second (Tier 1). The request accepts start, end, metrics, and filters parameters. The response body contains a status field (pending, running, done) and a url to download the CSV once complete — you must poll for completion, typically with a 30-second interval.

Method 4: Contacts and Accounts CSV Export

There are two ways to export your Front contacts: either directly from your Contacts Manager, or through Front's Contacts API endpoints.

UI export

To export your contacts directly from your Contacts Manager, select one of your contacts tabs, then click Export at the top. Select whether you'd like to export Shared contacts, Private contacts, or Shared and auto-created contacts. Click Generate export.

Accounts can similarly be exported to CSV from the Accounts Manager. Account records include company name, domain, custom fields, and linked contact IDs — but the CSV export does not include the full contact records for linked contacts. You must export contacts and accounts separately and join them on contact ID in your target system.

API export

The GET /contacts endpoint returns paginated contact records including handles (email, phone, social), custom fields, lists, and linked account references. The API returns all handles as a list in one field. Filter by handle.source to separate handle types (email, phone, Twitter, etc.).

The Contacts API supports updated_after and updated_before Unix timestamp filters, making it suitable for incremental delta sync rather than repeated full exports. When working with dates in the Front API, use Unix time format with 3-digit precision (milliseconds).

The Accounts API (GET /accounts) has equivalent structure: paginated, cursor-based, with custom field support and updated_after filtering. Accounts have their own custom field definitions independent of contact custom fields — export the field schemas for both resources before extracting values, using GET /accounts/custom_fields and GET /contacts/custom_fields.

The Core API exposes endpoints to list custom fields for Accounts, Contacts, Conversations, and Inboxes. Build a complete field mapping before exporting to avoid orphaned values in your target system.

Data Portability Gaps: What Front Does Not Let You Export

The central portability risk: There is no single export that gives you everything. A complete extraction requires combining the support export for bulk shared inbox data, the API for comments, tags, attachments, and individual inboxes, and the UI exports for contacts and analytics. Missing any layer leaves gaps in your target system.

If you are evaluating alternatives, see How to Migrate from Front to Zendesk for target-side transformation guidance.

Building a Complete Front Data Export

If you need a comprehensive export — for migration, backup, or compliance — here is the sequencing that works.

Step 1: Estimate your data volume

Before anything else, use Front's analytics dashboard or POST /analytics/reports to get a conversation count by inbox and date range. This scoping step determines whether you are looking at 10 hours or 200 hours of extraction time, and whether you need to request a rate limit increase before starting.

Step 2: Request the support-assisted export

File the request early. Front will acknowledge your data export request within 72 hours. Ask for both CSV and EML formats. Include knowledge base names if applicable. This process runs in parallel with your API work and typically takes 3–7 business days for large accounts. The support export is the only way to get knowledge base content.

Step 3: Export contacts and accounts via the UI

This is fast and self-service. Export shared contacts, private contacts, and accounts as separate CSV files from the Contacts Manager and Accounts Manager. This gives you the contact/account baseline before you run the API extraction.

Step 4: Generate an API token

Navigate to Settings → Developers → API Tokens. Create a token with read scopes for conversations, contacts, tags, custom fields, inboxes, teammates, and analytics. Enable Private resources scope if you need individual inbox data. The token's inbox access is scoped to whatever the generating admin can access — verify this before starting a large extraction.

If you are running automated integrations alongside the migration, consider registering an OAuth application to use the separate 120 rpm rate limit pool and avoid contention.

Step 5: Run the API extraction

Use Front's sample export application as a starting point, or build your own script. The critical extraction sequence:

1. List all inboxes → GET /inboxes
2. List all tags → GET /tags (paginated)
3. List all custom field definitions → GET /contacts/custom_fields, GET /conversations/custom_fields, GET /accounts/custom_fields
4. Iterate conversations per inbox → GET /inboxes/{id}/conversations (paginated, max 100 per page)
5. For each conversation → GET /conversations/{id}/messages and GET /conversations/{id}/comments
6. For each message with attachments → download attachment binaries via authenticated GET to the attachment URL

Front stores attachment metadata inside the message payload:

"attachments": [
  {
    "id": "fil_12345",
    "filename": "invoice.pdf",
    "url": "https://api2.frontapp.com/download/fil_12345",
    "content_type": "application/pdf",
    "size": 102400
  }
]

To download a file, make an authenticated GET request to the url value. Save the binary output to local disk or cloud storage and map the file path to the original message ID in your staging database. Always verify content_type and handle HTTP 404 gracefully — files linked via external integrations may not be hosted by Front.

Here is a Python extraction script with rate limit handling and cursor pagination:

import requests
import time
 
BASE_URL = "https://api2.frontapp.com"
HEADERS = {"Authorization": "Bearer YOUR_API_TOKEN"}
 
def paginated_get(url, params=None):
    """Follow Front's cursor pagination until no more pages."""
    results = []
    while url:
        resp = requests.get(url, headers=HEADERS, params=params)
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 60))
            time.sleep(retry_after)
            continue
        resp.raise_for_status()
        data = resp.json()
        results.extend(data.get("_results", []))
        url = data.get("_pagination", {}).get("next")
        params = None  # params are baked into the next URL
    return results
 
# List all inboxes
inboxes = paginated_get(f"{BASE_URL}/inboxes", {"limit": 100})
 
# For each inbox, get conversations
for inbox in inboxes:
    conversations = paginated_get(
        f"{BASE_URL}/inboxes/{inbox['id']}/conversations",
        {"limit": 100}
    )
    for convo in conversations:
        messages = paginated_get(
            f"{BASE_URL}/conversations/{convo['id']}/messages"
        )
        comments = paginated_get(
            f"{BASE_URL}/conversations/{convo['id']}/comments"
        )
        # Process and store messages + comments

A note on comment ordering: The comments endpoint returns results newest-first. If you are replaying conversation threads in a target system, reverse comment order before import to preserve chronological context.

A note on attachment scale: Attachment downloads are the most time-intensive part of any extraction with rich message histories. Each attachment requires a separate HTTP request. An account with 50,000 conversations averaging 2 attachments per conversation requires 100,000 additional download requests. Budget this separately from your API call time estimates.

For a practical estimate of total API time:

Total API calls ≈ (conversations × 3) + contacts_pages + tags_pages

# "× 3" because each conversation needs:
#   1 call to list messages
#   1 call to list comments
#   1+ calls to list paginated messages (if thread is long)

# Attachment downloads are separate and not quota-bound
# At 100 rpm (Professional plan):
# 50,000 conversations ≈ 150,000+ API calls ≈ 25+ hours (API only)
# Attachment downloads add wall-clock time but not API quota

Step 6: Export analytics data

From the Analytics dashboard, export Messages and Events CSVs for your required date range. This gives you response time metrics and SLA performance data that is not available from the conversation API.

Step 7: Reconcile and validate

Cross-reference conversation counts from the support export against your API extraction. Verify that individual inbox conversations (API-only) are captured. Spot-check attachment downloads and confirm comments are associated with the correct conversations. Use Front conversation IDs — not inbox membership — as your deduplication keys throughout.

How Long Does a Full Front Export Take?

Timeline depends on data volume and your plan's rate limit. These figures cover the API extraction phase only (conversations, messages, and comments). Attachment downloads add wall-clock time but do not consume API quota once attachment metadata is retrieved.

These estimates assume approximately 3 API calls per conversation (messages list, comments list, metadata). Long-threaded conversations with dozens of messages require additional paginated calls to the messages endpoint. The support-assisted export runs independently — typically 3–7 business days for large accounts, regardless of API plan.

OAuth optimization: If you register an OAuth application and run the extraction under OAuth credentials, the separate 120 rpm pool is available regardless of plan tier. For Starter plan accounts (normally 50 rpm), this nearly triples throughput at no additional cost — cutting a 30–50 hour extraction for 25,000 conversations to approximately 12–20 hours.

Edge Cases and Common Pitfalls

Merged conversations return redirects

If a conversation was merged into another, the original conversation ID becomes an alias. Calling child endpoints (messages, comments) on the old ID returns a 301 redirect. Your HTTP client must follow redirects, and you must deduplicate merged messages against the canonical conversation to avoid double-counting.

Massive threads require pagination on message endpoints

Front allows exceptionally long email chains. A single conversation can contain hundreds of messages. The messages endpoint is paginated using the same cursor mechanism as top-level list endpoints. Failing to paginate message requests will silently truncate thread histories — there is no error, just missing data.

API timeout errors on large conversations

Calling the Events endpoint on conversations with years of history can produce a 504 Gateway Timeout. Implement exponential backoff: wait 5 seconds after the first failure, 10 seconds after the second, 20 seconds after the third. Log the conversation ID and continue — retry the specific conversation separately rather than halting the entire extraction.

Forgetting individual inbox data

The support export covers only shared inboxes. If agents use individual inboxes for personal customer emails, that data must come from the API — and only if the token has Private resources scope and the inbox owner has granted access.

Losing internal comments

Comments are a separate API resource from messages. If your migration script pulls only messages, you lose all internal context. Comments do not appear in the support export either. The comments endpoint returns results newest-first — reverse the order before importing into a target system.

Tag and custom field orphaning

Tags are listed separately from conversations. Capture tag-to-conversation associations from each conversation object's tags array. Export field definitions first (GET /conversations/custom_fields, etc.), then values per resource. Importing values without the field schema in the target system orphans the data.

Multi-inbox deduplication

Conversations can belong to more than one inbox. If you iterate conversations per inbox, you will encounter the same conversation ID multiple times. Use conversation ID and message ID — not inbox membership — as your deduplication keys.

Attachment 404s at scale

Not all attachments listed in message payloads are hosted by Front. Files linked through certain integrations (e.g., Google Drive links embedded in messages) may appear in the attachments array but return HTTP 404 when downloaded. Handle 404 responses gracefully: log the attachment ID, filename, and parent message ID, then continue.

Timestamp precision

When working with dates in the Front API, use Unix time format with 3-digit precision for timestamps. Millisecond precision matters for updated_after filters — rounding to seconds can cause records to be missed or duplicated in delta syncs.

Continuous Sync and Webhook-Based Export

If the goal is near-real-time replication rather than a one-time bulk export, Front offers webhooks alongside the polling-based API.

Front webhook types:

• Application webhooks: Configured at the workspace level. Deliver all event types to a single endpoint. Event types include conversation.created, conversation.updated, message.created, comment.created, conversation.assigned, conversation.tag_updated, and others.
• Rule webhooks: Triggered by automation rules when specific conditions are met. Less reliable for data completeness — rule webhooks time out after 5 seconds and are not retried on failure.

A sample Front webhook payload for message.created:

{
  "type": "message.created",
  "payload": {
    "id": "msg_abc123",
    "conversation": {
      "id": "cnv_xyz789",
      "subject": "Invoice question"
    },
    "author": {
      "id": "tea_def456",
      "email": "agent@company.com"
    },
    "body": "<p>Hi, here is your invoice...</p>",
    "text": "Hi, here is your invoice...",
    "attachments": [],
    "created_at": 1719792000.123
  }
}

Webhook payloads deliver the full message body inline — unlike the API, you do not need a separate call to retrieve content. However, do not rely on webhooks as your sole data ledger:

• Rule webhooks do not retry on delivery failure
• Network timeouts, server restarts, and deployment windows create gaps
• Use the Events API (GET /events) as a reconciliation layer: poll it periodically to detect events your webhook consumer may have missed
• Use the Contacts API updated_after filter for contact delta sync
• Reserve conversation search for targeted recovery jobs, not steady-state backfill

GDPR and Data Subject Access Requests

If you are exporting for GDPR compliance, the support-assisted export covers shared inbox conversations but excludes individual inbox data and contacts. For a complete data subject access request covering all personal data, you must supplement with:

• API-extracted contact records (including all handles and custom fields)
• Individual inbox conversations (API, with Private resources scope)
• Account records linked to the data subject

Front's support team can advise on GDPR-specific requests. File GDPR requests separately from migration exports — they follow a different review process and may be handled by a different team with different timelines.

Vendor Lock-In and Data Transformation

Because Front's data model is conversation-centric rather than ticket-centric, you cannot take the JSON output and POST it directly to Zendesk, HubSpot, or Intercom. Migrating to a traditional helpdesk requires explicit schema transformation:

• Identify the first inbound message in each conversation to serve as the "ticket description"
• Map all subsequent messages as public replies or agent responses
• Translate Front tags into the target platform's custom fields or labels
• Convert Front internal comments into internal notes
• Rebuild contact and account associations using the target platform's customer and organization objects
• Map Front assignee IDs to target platform agent IDs (requires a teammate export and cross-reference table)

Pulling the data out of Front is only the first half of the problem. Transforming threaded conversation data into a ticket-based schema — where every ticket has exactly one opener, one or more replies, and discrete status transitions — is where the real engineering complexity lies.

When to DIY vs. When to Get Help

DIY makes sense when:

• You have fewer than 10,000 conversations
• You are on a Professional or Enterprise plan (100+ rpm)
• You have an engineer available for 2–3 days of scripting and testing
• You do not need to preserve complex tag hierarchies, custom field mappings, or attachment fidelity at scale

Get help when:

• You have 50,000+ conversations and cannot absorb 60–100+ hours of API extraction time
• You need attachments, comments, tags, and custom fields preserved with full fidelity across all inbox types
• Your target platform has its own import API with rate limits (two-sided bottleneck that requires coordinated pacing)
• Compliance or audit requirements mean you cannot afford missed records or a redo

At ClonePartner, we have built extraction pipelines for Front accounts ranging from 5,000 to 500,000+ conversations. The pattern is always the same: combine the support export for bulk EML data, layer in API extraction for comments, tags, and attachments, use the OAuth rate limit pool where contention is a concern, reconcile against analytics exports, and validate everything before pushing to the target platform.

Targeted Extraction with Search Queries

If you do not need a full export, Front's conversation search API lets you extract a targeted slice. The endpoint is GET /conversations/search/{query} with a URL-encoded query string.

# Exact phrase + inbox + date filter + open status
GET /conversations/search/%22refund%20requested%22%20inbox:support%20after:1719792000%20is:open?limit=100
 
# Tagged conversations for a specific recipient
GET /conversations/search/tag:vip%20recipient:jane%40acme.com%20is:archived?limit=100

Front search supports up to 15 filters combined with AND logic. Results are ordered by last activity with no option to change sort order, which makes search useful for targeting a slice but not for chronological replay. The search endpoint is also subject to the 40% proportional rate limit — prefer list endpoints for full-history extractions.

Conversations in Trash or Spam are excluded from results by default. Include is:trashed or is:spam explicitly in the query string to retrieve them.