Freshdesk to Front Migration: API Limits, Mapping & Methods

Migrating from Freshdesk to Front is a data-model translation problem. Freshdesk organizes support around tickets — structured records with statuses, priorities, groups, agents, and custom fields. Front organizes everything around conversations — collaborative message threads that live inside shared inboxes. Every ticket, note, attachment, and custom field value has to be extracted from one model and written into the other, and the structural gaps between them are where data silently disappears.

This guide covers the exact API constraints on both sides, a complete field-mapping table, a comparison of migration methods (including why Front's own importer is effectively deprecated), and a step-by-step preparation workflow — so you can move your team to Front without losing ticket history or operational context.

For a deeper look at Front's architecture and omni-channel capabilities, see Mastering Front: A Technical Deep Dive. If you are still evaluating the move, Why Forward-Thinking Teams Are Choosing Front covers the strategic case.

Why Teams Move from Freshdesk to Front

The typical driver is a shift from traditional ticketing to collaborative inbox. Freshdesk is built for transactional support — agents work tickets in a queue, follow rigid process flows, and hand off via groups. Front is built for teams that need to collaborate across departments on customer threads without switching tools.

Common triggers:

• Cross-functional collaboration needs. Teams that involve sales, ops, or engineering in customer threads find Freshdesk's siloed group model limiting.
• Multi-channel unification. Front aggregates email, SMS, WhatsApp, social, and live chat into a single inbox natively. Freshdesk requires toggling between Freshdesk, Freshchat, and Freshcaller.
• Outgrowing ticket-centric UX. Growing teams with relationship-driven support — logistics, fintech, B2B SaaS — often find Freshdesk's impersonal ticket IDs at odds with the customer experience they want to deliver.

The decision to move is usually sound. The risk lives in the migration itself — specifically in how you handle the data translation between two fundamentally different data models.

Freshdesk to Front Data Mapping: What Goes Where

Freshdesk is ticket-centric. Front is conversation-centric. A Freshdesk ticket has a requester, an assigned agent, a group, a status (Open, Pending, Resolved, Closed), a priority, a source, custom fields, and a flat list of conversations (replies and notes). A Front conversation has a recipient, an assignee (teammate), lives in one or more inboxes, and contains a thread of messages and comments.

Here is the mapping that matters:

The status mapping deserves special attention. Freshdesk supports Open, Pending, Resolved, Closed, and any number of custom statuses. Front supports Open, Archived, Trash, and Spam. Most migrations map Resolved/Closed → Archived and Pending/Open → Open, then preserve the original Freshdesk status as a tag for audit purposes.

Two edge cases cause trouble more often than teams expect. First, Front contacts cannot share the same email address or phone number across multiple contact records. Second, Front account domains can belong to at most one account. If your Freshdesk data has duplicate contacts, shared catch-all addresses, or multiple companies using the same domain, clean that data before you import. (help.front.com)

One more structural mismatch to plan for: Front's imported message API only accepts message types email, sms, intercom, or custom. Freshdesk history can include phone, forwarded email, tweet, survey feedback, or Facebook-originated content. If your Freshdesk instance is multi-channel, normalize those source types deliberately instead of assuming a 1:1 channel mapping. (dev.frontapp.com)

API Limits and Technical Constraints

Any API-driven migration has to read from Freshdesk and write to Front. Both platforms enforce rate limits that directly govern how fast you can move data.

Freshdesk API Rate Limits

Freshdesk enforces per-minute rate limits based on your plan tier. The limit applies account-wide — it does not matter how many agents or IP addresses make the calls.

Per-endpoint sub-limits are the constraint most teams miss. Even on a Growth plan with 200 calls/min total, the Tickets List endpoint is capped at roughly 20 calls/min. At 100 records per page, that is a maximum of 2,000 ticket stubs per minute — before you fetch conversations, attachments, or contacts. (developers.freshdesk.com)

Pagination ceiling: The Freshdesk API returns a maximum of 100 records per page (default 30). The search/filter endpoint (/api/v2/search/tickets) is further limited to 30 records per page with a hard cap of 10 pages — 300 tickets maximum per filtered query. For accounts with 50,000+ tickets, you must use the list endpoint with updated_since windowing to avoid hitting the deep pagination wall. Freshdesk explicitly warns against deep pagination beyond page 500 because response times degrade severely. (developers.freshdesk.com)

Conversation extraction gotcha: The embedded conversation view (/tickets/[id]?include=conversations) returns up to ten conversations per ticket and consumes extra API credits. For tickets with more than ten events, you must use the dedicated List All Conversations endpoint (/api/v2/tickets/[id]/conversations) or your migration will silently ship partial thread history. (developers.freshdesk.com)

Front API Rate Limits

Front's API rate limits are plan-tiered and enforced globally across all endpoints:

Front also enforces burst limits: 5 requests per second per resource type (1/sec for exports). Partner integrations authenticated via OAuth get a separate 120 rpm limit per company, which does not count against the customer's own limit — a meaningful throughput difference compared with a DIY script that burns the customer-owned API budget directly. (dev.frontapp.com)

Front pagination is token-based, not page-number-based. Follow _pagination.next rather than assuming fewer results means you reached the end. (dev.frontapp.com)

Front offers rate limit add-ons (300 additional calls/min per add-on) and higher limits on Scale plans. If you are migrating more than a few thousand conversations, requesting a temporary limit increase from Front before the migration is worth the ask.

Async import behavior: Front's imported message endpoint returns 202 Accepted, which means write success and object availability are not the same moment. If your QA script checks Front too soon after a write, it will flag false negatives and trigger unnecessary re-runs. Build a delay between import and validation. (dev.frontapp.com)

What This Means in Practice

A migration of 20,000 Freshdesk tickets with an average of 5 conversations each requires:

• ~20,000 API calls to list and fetch tickets from Freshdesk
• ~100,000 calls to fetch all conversations
• Attachment downloads (variable, not rate-limited but bandwidth-constrained)
• ~20,000+ calls to create conversations in Front
• ~100,000+ calls to import messages into those conversations

On a Freshdesk Growth plan (200/min) and Front Growth plan (100/min), the Front write side is the bottleneck. Without proper throttling, backoff, and queue management, a DIY script will spend more time handling 429 errors than moving data.

Ticket History, Attachments, and Inline Images

Conversation Threading

Freshdesk tickets contain a flat list of conversations — replies and notes in chronological order. Front threads messages using external_conversation_id. A well-built migration script sets a consistent external_conversation_id per Freshdesk ticket so all replies and notes land in the same Front conversation thread. (dev.frontapp.com)

The correct rebuild sequence: create the Front conversation from the original ticket message, append each customer-visible reply as an imported message in chronological order, and write each Freshdesk private note as a Front comment. Front comments support attachments, so private notes with files do not need to be flattened into plain text.

Inline Images

Freshdesk stores inline images as references within the HTML body of ticket conversations — often as base64-encoded data or links to Freshdesk's CDN. When a migration tool ignores inline images, agents opening old tickets in Front see broken image placeholders — the screenshot that explained a bug, the annotated workflow diagram, gone.

Preserving inline rendering requires rewriting the HTML body so that the new Front-side file references are valid. If a tool only copies files as attachments, agents get the message body plus a loose attachment instead of the original inline layout. Help Desk Migration's own Front checklist explicitly confirms that inline images are not migrated in its standard path.

An engineer-led migration extracts these references, downloads the image binaries, re-uploads them to Front, and rewrites the HTML body to point to the new locations. It is extra work, but it is the difference between a usable archive and a broken one.

Attachment Size Limits

Freshdesk allows attachments up to 20 MB. Front supports attachments up to 25 MB per file via its API. The target can accept typical Freshdesk files, but test your largest attachments during the pilot run to catch any edge cases before the full migration.

The 3 Migration Options: Native, SaaS Tools, and Engineer-Led

Option 1: Front's Native Freshdesk Importer

Front has a built-in Freshdesk importer under Settings → Imports. Here is what you need to know:

• Front's own help center states it is "not actively maintained" and recommends using migration partners instead. (help.front.com)
• It imports a maximum of 9,000 of your most recent Freshdesk tickets. Running it again does not fetch the next batch — it returns the same set.
• It maps Groups → Inboxes, Agents → Teammates, Tickets → Conversations.
• It handles assignee, status, and file attachments.
• It does not handle custom fields, inline images, tags, or organizations.
• Import speed is approximately 3,000 Freshdesk tickets per hour.

When to use it: You have fewer than 9,000 tickets total, no custom fields or tags you need to preserve, and no inline images in your ticket history. It is free and requires no technical setup.

When to avoid it: Any account larger than 9,000 tickets, or any team that relies on custom field data, tags, or inline images for operational context.

Option 2: SaaS Migration Tools (Help Desk Migration / Import2)

Help Desk Migration (Relokia) offers an automated migration wizard that connects Freshdesk and Front via API. It handles teammate matching, status mapping, and tag transfer through a self-service UI.

But its Front integration has hard limitations. According to HDM's own checklist, the following will not be migrated to Front:

• Organizations
• Custom fields
• Inline images
• Knowledge base data
• Macros, triggers, automations

For a direct comparison, see ClonePartner vs Help Desk Migration: 2026 Price & Feature Comparison.

Import2 offers a similar one-click approach but shares the same fundamental constraint: standardized field mapping means complex custom fields and inline attachments require manual intervention or fail without warning. It is a reasonable fit for straightforward, standard-schema migrations. The trade-off is structural — you are working inside a connector model with standard mappings first, which is rarely where oddball help desk history, cross-object dependencies, or inline-image preservation live.

When to use them: Standard migrations where you primarily need tickets, contacts, and tags moved to Front and can live without custom fields and inline images.

When to avoid them: Any migration where custom field data, inline images, or organization records are operationally important.

Option 3: Engineer-Led API Migration (ClonePartner)

A custom API migration scripts the entire data transfer — reading from Freshdesk's REST API v2 and writing to Front's Core API and imported message endpoints. This is the only approach that can:

• Preserve custom fields by writing them to Front's conversation, contact, or account custom fields — or encoding them as structured tags when field limits are a concern
• Handle inline images by extracting embedded image references from Freshdesk HTML bodies, downloading the binaries, and re-attaching them to Front conversations with correct HTML references
• Migrate organizations and link them to the correct accounts in Front
• Manage rate limits programmatically with exponential backoff, queue management, and parallel workers that respect both Freshdesk's per-endpoint sub-limits and Front's burst limits
• Map complex statuses — converting Freshdesk's custom statuses into Front tags while setting the correct Open/Archived state
• Use full conversation endpoints to extract complete thread history, including tickets with more than 10 conversation events that the embedded view silently truncates

This is the approach ClonePartner uses as an official Front migration partner, listed directly in Front's help center alongside Help Desk Migration. (help.front.com)

Step-by-Step Guide to Preparing Your Freshdesk Data

Before any migration method, these preparation steps reduce errors and speed up the transfer.

Step 1: Audit Your Freshdesk Account

Count your tickets, contacts, companies, and agents. Check your Freshdesk plan to determine your API rate limit. Identify custom fields that carry operational data — order IDs, account tiers, escalation reasons — these need explicit mapping decisions.

Sort tickets by Date created → Any time to get your total count. If you are over 50,000 tickets, expect multi-hour export times on Growth plans. Pull examples of large, messy, old tickets on purpose — not just clean recent ones.

Use Freshdesk's ticket field metadata endpoint (/api/v2/ticket_fields) to build your mapping sheet from actual field definitions — names, labels, required flags, choice sets, and dependent-field behavior — rather than guessing from exported values. (developers.freshdesk.com)

Freshdesk's search API is useful for building representative samples:

status:2 OR status:3 OR status:6 OR status:7
agent_id:null
type:'Problem' AND tag:'billing'
tag:null

The point of those queries is coverage. If your sample only includes clean, recently updated tickets, your migration test is lying to you.

Step 2: Clean Up Tags and Groups

Remove duplicate tags, typos, and unused groups. Every Freshdesk group maps to a Front inbox — if you have 30 groups but only 8 are active, clean up now. Fewer inboxes in Front means simpler routing rules later.

Step 3: Map Custom Fields to Front Targets

Decide the target for each Freshdesk custom field:

• High-cardinality text fields (order IDs, case numbers): Write to a Front conversation custom field or an internal comment with a structured prefix.
• Categorical fields (department, product line): Convert to Front tags with a namespace (e.g., product:widget-pro) or a Front custom field dropdown.
• Boolean/checkbox fields: Convert to presence/absence of a tag.

Document this mapping in a spreadsheet. Remember Front's 50-custom-field-per-category limit when planning field parity. Your migration partner or script will need this mapping before writing any data.

Step 4: Generate API Credentials

Freshdesk: Navigate to My Profile Settings → View API Key and copy it. This is a per-agent key tied to your admin account.

Front: Navigate to Settings → Developers → API Tokens → Create API Token. Enable both Shared and Private scopes. Store the token securely — it is shown only once.

Step 5: Disable Automations and Notifications

In Freshdesk, disable Dispatch Rules, Supervisor rules, Observer rules, and all Email Notifications (Agent and Requester). This prevents automation rules from modifying tickets during export.

In Front, disable any Rules that auto-assign, auto-tag, or auto-archive incoming conversations. You do not want migrated data triggering routing logic.

Step 6: Run a Test Migration

Whether you use an automated tool or an engineer-led approach, always test on a subset first. Pick 20–50 tickets that represent your edge cases: tickets with inline images, multi-reply threads (especially those with more than 10 conversation events), private notes, custom field values, and large attachments. Verify every field in Front before committing to a full run.

For a full pre-migration and post-migration checklist, see the Front Migration Checklist. For deeper guidance on field mapping methodology, see Your Ultimate Guide to Data Mapping for a Flawless Helpdesk Migration.

What to Watch Out For

A few failure modes that catch teams off guard:

• Private note timestamps. Front sets comment creation dates to the migration date, not the original Freshdesk date. The original timestamp can be preserved in the comment body, but it will not sort correctly in Front's timeline. Plan for this.
• Agent matching. If a Freshdesk agent's email does not match any Front teammate, their tickets get reassigned to a default teammate. Create all teammates in Front before starting the migration and verify email matches.
• Freshdesk search API cap. The /api/v2/search/tickets endpoint caps at 300 results (10 pages × 30 records). If your migration script uses this endpoint for filtered exports, it will silently miss tickets. Use the list endpoint with updated_since windowing instead.
• Front workspace scoping. All mapped inboxes must belong to the workspace you select during import. If an inbox is in a different workspace, the migration fails silently for those tickets.
• Contact uniqueness. Front contacts cannot share the same email address or phone number. Front account domains can belong to at most one account. Duplicate contacts or shared domains in Freshdesk will cause import failures if not cleaned beforehand. (help.front.com)
• Async import timing. Front's imported message endpoint returns 202 Accepted. If your validation script runs too soon after writing, it will flag missing records that have not yet been processed. Build a delay between import and QA.
• Embedded conversation truncation. The /tickets/[id]?include=conversations shortcut returns at most 10 conversation events. Use the dedicated conversations endpoint for full history extraction.

Why ClonePartner Is the Official Front Migration Partner

Front lists ClonePartner directly in its help center as a recommended migration partner for Freshdesk-to-Front moves. This is not a marketplace listing — it is documented in Front's own Freshdesk history import article alongside Help Desk Migration. (help.front.com)

What that means in practice:

• Custom field preservation. We map structured custom field data to Front's conversation, contact, and account custom fields — or to tags and internal comments when that fits your workflow better. Automated tools drop this data entirely.
• Inline image handling. Our scripts extract, download, and re-attach inline images so your historical context survives the migration intact.
• Rate limit engineering. We build exponential backoff, per-endpoint throttling, and queue management into every migration script. Our partner OAuth integration uses a separate 120 rpm rate limit bucket that does not count against your company's standard Front API budget. (dev.frontapp.com)
• Zero downtime execution. Your support team keeps working in Freshdesk during the migration. We handle delta syncs to catch tickets created or updated during the transfer window, so nothing is lost in the cutover. See Zero-Downtime Helpdesk Migration: How to Keep Support Running During the Move.

For a real-world example, see How ClonePartner Enabled MobiMed's 15% Efficiency Gain on Front within the First Month.

Making the Call

For teams with fewer than 9,000 tickets and no custom field dependencies, Front's native importer is free and functional — just know it is unmaintained and you are on your own if something breaks.

For teams with standard data and a tolerance for losing custom fields and inline images, Help Desk Migration's wizard gets the job done at a predictable price.

For teams where custom fields carry operational meaning, where inline images document real customer issues, or where ticket volumes exceed what automated tools handle gracefully — an engineer-led API migration is the only approach that preserves your full data context.

Freshdesk to Front is not hard because exporting data is hard. It is hard because getting the right history into the right Front objects, under rate limits, without silent data loss, takes design work. The honest trade-off: an engineer-led migration is overkill for tiny, clean datasets. It is the right route for serious ones.