--- title: "How to Export Data from Front: Methods, API Limits & Gaps" slug: how-to-export-data-from-front-methods-api-limits-gaps date: 2026-08-24 author: Abdul categories: [Front, Migration Guide, Help Desk] excerpt: "Front has no single bulk export. Learn the four extraction methods — support export, Core API, analytics CSV, and contacts export — plus rate limits and portability gaps." tldr: "Getting all your data out of Front requires combining four methods: support-assisted export, Core API, analytics CSVs, and contacts UI export. No single path covers everything." canonical: https://clonepartner.com/blog/how-to-export-data-from-front-methods-api-limits-gaps/ --- # 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](https://clonepartner.com/blog/blog/zendesk-to-front-migration-the-2026-technical-guide/) or [Freshdesk](https://clonepartner.com/blog/blog/how-to-export-data-from-freshdesk-methods-api-limits-mapping/) 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](https://clonepartner.com/blog/blog/front-migration-checklist/) for the full picture. For a deep dive on Front's architecture, see [Mastering Front: A Technical Deep Dive](https://clonepartner.com/blog/blog/ultimate-guide-front-2026/). ## 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 | Data Covered | Format | Self-Service? | Includes Attachments? | |---|---|---|---|---| | Support-assisted account export | Shared inbox conversations, messages, discussions | CSV, EML on request | No — requires Support ticket | No | | Core API | Conversations, messages, comments, contacts, tags, custom fields, inboxes, teammates | JSON | Yes — requires API token | Yes (per-message download) | | Analytics export (UI) | Message-level and event-level metrics | CSV | Yes | No | | Contacts/Accounts CSV export (UI) | Contact and account records | CSV | Yes | N/A | ## 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. > [!WARNING] > **Request EML explicitly.** By default, the support export delivers CSV only. If you plan to import into a mail-based system or another helpdesk that accepts EML, you need to ask for EML format in your initial request. Retrofitting later means another wait and another 72-hour acknowledgment window. ## 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. | Plan | Standard Rate Limit | OAuth Rate Limit (separate pool) | |---|---|---| | Starter | 50 rpm | 120 rpm | | Professional | 100 rpm | 120 rpm | | Enterprise | 200 rpm | 120 rpm | 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. > [!NOTE] > **Monitor your rate limit with response headers.** Every API response includes `X-RateLimit-Limit`, `X-RateLimit-Remaining`, and `X-RateLimit-Reset`. When you exceed the limit, you receive a `429 Too Many Requests` response with a `Retry-After` header. Honor that header — sending requests before the reset window expires resets the delay further. ### Key endpoints for data extraction | Endpoint | What It Returns | |---|---| | `GET /inboxes` | All inboxes | | `GET /conversations` | List all conversations (paginated) | | `GET /conversations/{id}/messages` | All messages in a conversation | | `GET /conversations/{id}/comments` | Internal comments on a conversation | | `GET /contacts` | All contacts (paginated) | | `GET /tags` | All tags (paginated) | | `GET /teammates` | All teammates | | `GET /conversations/search/{query}` | Search conversations with filters | | `GET /contacts/custom_fields` | Custom fields on contacts | | `GET /conversations/custom_fields` | Custom fields on conversations | | `GET /accounts/custom_fields` | Custom fields on accounts | | `GET /events` | Event stream (15 items/page max) | | `POST /analytics/exports` | Request analytics data export | **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. ```json { "_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](https://dev.frontapp.com/docs/sample-application). 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. > [!TIP] > **Analytics exports are metrics, not message content.** The analytics CSV gives you metadata — timestamps, response times, assignees — not message body text. For message content, you need the API or the support-assisted export. 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 | Data Type | Exportable? | Method | Notes | |---|---|---|---| | Shared inbox conversations | ✅ | Support export, API | Support export excludes comments | | Individual inbox conversations | ⚠️ | API only | Not in support export | | Internal comments | ⚠️ | API only | Not in support export; returned newest-first | | Attachments | ⚠️ | API only | One authenticated download per attachment | | Tags | ⚠️ | API only | Not in support export | | Contacts | ✅ | UI CSV, API | Support export excludes contacts | | Accounts | ✅ | UI CSV, API | Export separately from contacts; join on contact ID | | Custom fields (conversations) | ✅ | API | Export field definitions before values | | Custom fields (contacts/accounts) | ✅ | API | Separate definitions per resource type | | Rules/Automations | ❌ | None | Must be manually recreated | | Message templates | ❌ | None | Must be manually recreated | | Knowledge base | ⚠️ | Support export only | Request alongside account export; separate files | | Analytics metrics | ✅ | UI CSV, API | Metrics only — no message body content | | SLA policies | ❌ | None | Configuration only — not exportable | | Signatures | ❌ | None | Must be manually recreated | | Drafts | ⚠️ | API only | Listable per conversation; no bulk endpoint | **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](https://clonepartner.com/blog/blog/how-to-migrate-from-front-to-zendesk-the-complete-technical-guide/) 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](https://dev.frontapp.com/docs/sample-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: ```json "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: ```python 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 ``` > [!NOTE] > **Concurrency does not help — with an important caveat.** Because Front's rate limit is enforced at the company level (not per token), running multiple API threads in parallel exhausts your request budget faster without increasing throughput. However, attachment downloads are I/O-bound rather than API-quota-bound. You can safely parallelize attachment binary downloads (e.g., with `concurrent.futures.ThreadPoolExecutor`) without consuming additional API quota — the download URLs are pre-signed and do not count against your rate limit once retrieved. Keep API calls serial; parallelize only the binary downloads. **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. > [!TIP] > **Use Front IDs as primary keys throughout.** Conversations can belong to more than one inbox, and analytics exports can repeat the same record once per inbox. Front conversation IDs and message IDs are the only stable deduplication surface. Keep the original Front IDs through all validation steps and map to destination IDs only at the final import stage. ## 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. | Data Volume | Starter (50 rpm) | Professional (100 rpm) | Enterprise (200 rpm) | |---|---|---|---| | 5,000 conversations | ~6–10 hours | ~3–5 hours | ~1.5–3 hours | | 25,000 conversations | ~30–50 hours | ~15–25 hours | ~8–13 hours | | 100,000 conversations | ~120–200 hours | ~60–100 hours | ~30–50 hours | 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`:** ```json { "type": "message.created", "payload": { "id": "msg_abc123", "conversation": { "id": "cnv_xyz789", "subject": "Invoice question" }, "author": { "id": "tea_def456", "email": "agent@company.com" }, "body": "

Hi, here is your invoice...

", "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. > Need a complete, verified export of your Front data — conversations, comments, attachments, tags, and all? Book a 30-minute call and we will scope it out. > > [Talk to us](https://cal.com/clonepartner/meet?duration=30) ## 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. ```bash # 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. ## Frequently asked questions ### Can I export all my data from Front myself? No. Front has no self-service full account export. You must contact Front Support for bulk shared inbox data (CSV/EML), use the Core API for comments, tags, attachments, and individual inbox data, and separately export contacts and analytics from the UI. No single method covers all data types. ### What is Front's API rate limit for data extraction? Front's API rate limit starts at 50 requests per minute (Starter), 100 rpm (Professional), and 200 rpm (Enterprise). Limits are enforced per company, not per token. You can purchase add-ons at $200/month per additional 100 rpm. The conversation search endpoint is further limited to 40% of your global rate limit. ### Does Front's support-assisted export include attachments and comments? No. The support-assisted account export includes shared inbox conversations and messages in CSV or EML format, but explicitly excludes attachments, internal comments, individual inbox data, contact records, tags, and message templates. You need the Core API to export those. ### How long does it take to export data from Front via the API? It depends on volume and plan. At 100 rpm (Professional), exporting 25,000 conversations with messages and comments takes roughly 15–25 hours of continuous API calls. Attachment downloads add significantly more time. Front's support-assisted export typically takes 3–7 business days. ### Can I export Front conversations to EML format? Yes, but only through the support-assisted export — and you must explicitly request EML format. The default is CSV only. The Core API returns message data as JSON, which you can programmatically convert to EML using open-source tools like the front-export package on GitHub.