What you can export from Help Scout and what you cannot
If you are facing a renewal, a price change, a data residency requirement or a decision to leave Help Scout, the first question is what you can take with you and in what form. Full conversation history comes out through the Help Scout API, which authenticates with OAuth 2. The CSV or Excel reporting export covers summary report data only. It is useful for management reporting and trend reviews, but it cannot rebuild an inbox. The API route is the one that carries threads, attachments and customer records, so any migration plan has to start there. Decide early which mailboxes, date ranges and object types must leave, because that scope determines how much API work you will need.
Per-plan rate limits shape how long a full pull takes. A mailbox with years of threads and attachments generates many requests, and a large export can run for an extended period, so schedule it as a background job rather than a one-off task. Before planning, confirm the current limits, the endpoints for conversations, threads, attachments and customers, and the authentication flow in Help Scout's developer documentation, since these details change over time. Then run a test pull against one small mailbox and check the record counts against the Help Scout interface.
Treat the reporting export as a complement, not a backup. Open a file from it and list its columns so your team knows exactly which fields are missing, such as thread bodies, attachments and customer profiles. Keep a log of every API request, including failed pages and retries, so you can prove completeness later. Store downloaded attachments in your own storage with a manifest that links each file to its conversation. This record matters if a renewal dispute, a regulator or an auditor asks how your conversation history was preserved after you left the platform.
Which data types come out through which export path
This table maps each Help Scout data type to the Inbox API over OAuth 2 and to the CSV or Excel reporting export. Use it to decide which path you need for each dataset and which limits to confirm before you start. The main takeaway is that reporting exports are for analysis, so full conversation content and attachments need the API.
| Data type | Inbox API via OAuth 2 | CSV or Excel reporting export | What to confirm |
|---|---|---|---|
| Conversations | Full conversation records, listed per mailbox and paged | Report-level fields and counts, not full message content | Status, spam and deleted filters, date range and paging limits for your plan |
| Threads | Customer replies, agent replies and notes, requested per conversation | Not included as message bodies | That replies, notes and forwarded messages all return, with timestamps and authors |
| Attachments | Metadata in JSON, then a separate file download for each attachment | Not included | Download access for every file, handling of inline images and total volume allowed |
| Customers | Customer profiles linked to conversations | Customer counts or report fields only | Whether custom fields, phone numbers and social profiles are returned |
| Mailboxes | Mailbox names and IDs visible to your OAuth app | Mailbox names as report dimensions | Which mailboxes your app credentials can read and whether all are listed |
| Saved replies | Confirm with Help Scout whether the API exposes them | Not included | If no API endpoint exists, plan to copy saved reply text from the web app |
| Tags | Tags attached to each conversation in the API response | Tag counts as report dimensions | That tag names and assignments come with each conversation record |
| Users | Agent accounts and roles visible to the OAuth app | Agent names as report dimensions | Which roles, inactive accounts and user fields the API returns |
What does not export cleanly and how to cover the gap
Help Scout exports carry conversation data well, but several items sit outside that data: report summaries, attachment files, Docs articles, configuration and credentials. Each gap below needs its own check and workaround, so test every item on a sample export before you depend on it.
Report exports omit conversation content
The CSV or Excel reporting export summarizes volumes, response times and team activity. It is built for analysis, so it should not be treated as a copy of the conversations. Pull full threads, internal notes and customer records through the Inbox API, then compare one exported conversation against the original to confirm which fields survive. Keep the report file as a separate record of volumes and dates in your archive.
Attachments need a **separate download pass**
Conversation exports can carry references to files without the file content, so confirm how attachments arrive in your test. Plan a download pass that stores each file under its conversation ID and writes size, type and checksum to a manifest. Check that duplicate or specially named files do not overwrite each other. In FreeScout, the free S3 Storage module can point attachments at an object store on your own servers.
Docs articles sit outside conversations
Help Scout Docs articles and collections are a separate content set from the conversation data in the Inbox API. Export them on their own, keep each article's original URL, and map collections to a destination. FreeScout offers knowledge base support through a paid module, while Chatwoot lists a Help Center portal in its feature set. Check that links from your support widget and emails still resolve after the move.
Workflows and saved replies need rebuilding
Automations, workflows and saved replies are configuration, not conversation history, so a data export rarely carries them. Before you exit, document each rule's trigger, condition and action, and copy the text of every saved reply. Rebuild them in the target and test each one against a sample ticket. FreeScout's Workflows module is a paid add-on, and Chatwoot lists automation, canned responses and auto-assignment in its feature set.
Passwords and integration tokens stay behind
User passwords and the tokens for connected apps do not leave the platform, so an export will not carry them. Plan a password reset or single sign-on login for every agent, and reconnect each mailbox and integration in the target. FreeScout uses OAuth for Microsoft 365 and Google Workspace mailboxes, so the account owner should re-authorize those connections during cutover. Write down every integration before you start so none are missed.
The order to run a complete export without losing history
This sequence moves Help Scout history into an archive you control, in an order where each stage can be checked against the one before it. The final archive holds customers, conversations, threads, attachments and management reports, each with a verified count and checksum.
Inventory mailboxes and expected volumes
Before any API call, list every mailbox, shared inbox and saved reply set in the account, and record the conversation and customer counts each mailbox shows in the Help Scout interface. Note which mailboxes hold legal, billing or patient records that need extra retention handling. Done when you have a signed-off inventory sheet with one row per mailbox and a baseline count for each, which later steps reconcile against.
Confirm API access and rate limits for the plan
Check in Help Scout's current API documentation and your plan terms that the account can use the Inbox API and what request limits apply to it. Ask Help Scout support to confirm any limit that is not stated clearly, since limits can differ by plan. Record the limits in the runbook so batch sizes and pauses are set from documented values rather than guessed. Done when the runbook states the confirmed limits and the batch settings are derived from them.
Register the OAuth 2 application and authorize access
An administrator registers an OAuth 2 application in Help Scout, then authorizes it with the scopes needed to read customers, conversations, threads and attachments. Use a dedicated service identity where the plan allows it, and store the client secret and tokens in a secrets manager rather than in scripts. Confirm the exact scope names in the current documentation before authorizing. Done when a test call returns the first page of conversations for one mailbox and the token refresh process has been tested.
Pull customers and conversations in date-ordered batches
Export customers first, then conversations and their threads, in batches sorted by creation date and paged with a stored cursor or page marker. Write each raw API response to disk as received, keyed by mailbox and batch number, so a failed run resumes from the last completed batch. Pause between batches to stay within the confirmed limits and log any throttled or failed requests. Done when each mailbox's exported conversation count matches the inventory baseline, and any gap is explained in the log.
Download attachments in a separate pass
Once conversation records are complete, collect attachment references from the thread data and download the files in a second pass. Keep each file under its conversation identifier and original file name, and record the expected size from the metadata. Attachments often fail more than other records, so retry failed downloads and list any that cannot be retrieved. Done when the file count and total size for each mailbox match the attachment references in the thread data, with exceptions listed by name.
Export reports for management records
Run the reporting export from Help Scout for the periods your records require, and save the CSV or Excel files alongside the API data. Treat these files as management summaries: check in the Help Scout documentation which fields they include, and do not assume they hold full thread content or attachments. Note the reporting period and filters used for each file. Done when each report file is saved with its parameters in the runbook and its totals are compared with the matching API counts.
Store the archive with dated folders and checksums
Place the customer, conversation, thread, attachment and report files into one dated archive folder with a fixed structure per mailbox. Generate a checksum for every file and store the checksum manifest beside the archive, then copy the archive to a second location under your retention controls. Restrict access to the archive to named roles. Done when the manifest lists every file, a checksum verification pass reports no mismatches, and the copy in the second location passes the same check.
Verify a sample against the live inbox
Select a sample of conversations from each mailbox, including old, long, and recently edited threads, and compare the archived thread text, participants and timestamps with the live inbox. Check that a sample of attachments opens and matches the recorded size. Record each comparison with the reviewer's name and the result. Done when the sample reconciliation log shows every selected item matched or has a documented explanation, and the archive owner has signed off.
API pull or reporting export: which path fits which need
The Inbox API is the route for a complete copy of conversations, threads, attachments and customers. It authenticates with OAuth 2, so your team registers an app in Help Scout and uses its credentials to obtain access tokens for the account. Treat the pull as a migration job that reads one resource at a time and writes to a staging store you control.
- OAuth 2 setup: Create the app with an account owner or administrator, store the client credentials in a secrets manager, and confirm token lifetime and refresh behavior in Help Scout's developer documentation before writing code.
- Pagination: Walk each list endpoint page by page until it is exhausted, save the last page reached, and make the job resumable so an interrupted run does not restart from the beginning.
- Retry handling: Back off on throttled responses, honor any retry timing the API returns, and retry transient server errors a limited number of times. Log every failed record by ID.
- Plan rate limits: Confirm the limits that apply to your plan and count requests per hour before scheduling. Run the pull in off-peak windows so live support traffic is not slowed.
- Attachments and threads: Fetch threads and attachments as separate calls, verify byte counts against the reported sizes, and keep original filenames and timestamps as evidence.
Before committing, confirm current endpoints, scopes, pagination parameters and rate limits in Help Scout's API documentation, since these can change.
The reporting export produces spreadsheet summaries of conversation and team activity. It suits management reporting, service reviews and audit summaries. It does not carry full message bodies, attachments or every thread, so it cannot serve as the system of record. The available report types, date ranges and columns are set by Help Scout and may depend on your plan.
- Management reporting: Volumes and response figures by mailbox, team or period fit leadership packs, service reviews and budget discussions.
- Audit summaries: Counts and date ranges help an assessor select a sample, after which the underlying records come from the API archive.
- Coverage limits: Expect summary rows rather than message text, attachments or internal notes. Verify this with a test export from your own account.
- Format handling: Check how CSV and Excel files handle long text, line breaks, time zones and non-English characters before loading them into a warehouse or a FreeScout or Chatwoot import.
- Repeatability: Save the report settings and date filters so any export can be reproduced later for an auditor.
Before relying on this path, export one known conversation and check its fields, then confirm the export options available on your plan in Help Scout's current reporting settings.
Most exits run both paths. The API pull builds the complete archive, and the reporting export gives the business readable figures and an independent cross-check. Running them side by side also exposes gaps, such as records the API returns that a report omits, or the reverse.
- Reconciliation: Compare conversation counts per mailbox and date range between the API archive and the report. Investigate every difference before cutover.
- Cutover timing: Stop live intake at a agreed moment, run a final full pull, then run a delta pull for changes made after the first full pull.
- Target mapping: Map Help Scout fields to the fields in FreeScout or Chatwoot in a shared spreadsheet, and use the report as the human-readable check on that mapping.
- Retention evidence: Store raw API responses, report files and the reconciliation log together, with checksums, so you can show what was exported and when.
- Ownership: Name who runs each path, who signs off the reconciliation, and who keeps the archive after the Help Scout subscription ends.
Confirm the current behavior of each path with Help Scout and in a test account before you set a cutover date.
What to plan before the Help Scout contract ends
A Help Scout exit touches contracts, people, legal records and live mail flow at once, so the work needs an order. The cards below follow the sequence most teams find useful: start early, settle ownership and retention in writing, decide what must be kept, then run the old and new inboxes side by side before cutover.
Start the export early
Begin the export well before the renewal date so there is time to test a small pull, find rate limit problems and repeat any failed batches. Export volume is the main timing driver: a mailbox with years of threads and large attachments takes far longer than a small shared inbox. Run a pilot on one mailbox first and measure how long it takes before you plan the full schedule.
Confirm owner and API access
Name the account owner and an administrator who can create OAuth 2 credentials for the Inbox API. Without these, the export cannot start, and a credential tied to one person can break when that person leaves. Confirm that the plan you hold includes API access, and check the rate limits that apply to it before you schedule bulk pulls.
Get retention terms in writing
Ask Help Scout in writing how long your conversations, attachments and customer records are retained after cancellation, and when they are deleted. Ask whether a deletion request can be made and what it removes. Keep the written answer with your exit records, since your compliance team will ask for it later.
Decide what must be kept
Work with legal, compliance and records owners to list the mailboxes, date ranges and threads that must survive for legal hold, audit or regulatory reasons. Note which fields and attachments those records need, since a reporting export may not include them. Export these first and verify them against the source before the account closes.
Plan a parallel run
Keep the Help Scout inbox receiving mail while the new system takes over, and document how forwarding, DNS and mailbox changes will happen. Customers who reply to old threads need a clear route, so decide how replies to pre-cutover conversations are handled. Do not switch the mail route until the new system has passed a test with real messages.
Budget people and hosting
Plan the staff time for export scripting, data checks and agent training, plus the hosting, email and backup work on the new side. Effort rises with the number of mailboxes, custom fields, saved replies and integrations that must be rebuilt. Ask your implementation partner for a quote based on a written scope, and confirm which items you will handle internally.
Questions teams ask before they export their Help Scout data
Can our team export Help Scout data without outside help?
Yes, if you have an engineer who can register an OAuth 2 app, call the Inbox API, page through results, and handle retries and rate-limit responses. The work is mostly scripting and validation, not configuration. The reporting export in the Help Scout interface is simpler to run, but it is built for performance summaries and cannot serve as a full archive. Confirm in Help Scout's current API documentation which roles can create API credentials on your plan, and whether your team has the time to build, test and rerun the script before a cutover date.
What drives the cost of a Help Scout data export?
The main cost is engineering time, and it rises with the number of conversations, threads, attachments, mailboxes and customers, plus the number of data shapes you need to map into the target system. Costs also rise when rate limits force a long, throttled run, when the target system needs custom import logic, or when you must reconcile records afterward. Export itself is a one-time cost. Recurring costs appear only if you keep Help Scout running during a parallel period or run repeat delta exports. When you ask for a quote, ask which items are fixed, which are estimated, and who maintains the script after handover.
How long does a full Help Scout export take?
The duration depends mainly on volume and on the request ceiling your Help Scout plan allows, because the Inbox API returns data in pages and enforces rate limits. Count conversations and threads per mailbox first, then measure how many requests a sample of one mailbox needs. Plan for failed requests, retries and a window outside peak support hours. Confirm the current rate limits for your plan in Help Scout's documentation before you commit to a date. Any timeline in a proposal should follow from those measured numbers and the written scope, not from a general estimate.
Do attachments and customer records come out with conversations?
Not automatically in every case, so check each object type separately. Conversations and threads are returned as their own resources, and customers are linked to them by identifiers rather than embedded in every record. Attachment content usually needs its own retrieval step, and the storage location and download behavior should be confirmed in the current Help Scout API reference. Your export should keep the links between threads, attachments and customers so the archive can be rebuilt in another system. Test a sample conversation with attachments end to end before you run the full job.
What does the Help Scout CSV or Excel report miss?
The reporting export is designed for metrics such as volumes and response performance, so it is a summary, not a message archive. It is unlikely to hold full thread bodies, attachments, customer profiles or the internal structure of each conversation. Open the file and list its columns against your archive requirements before relying on it. Use it to cross-check totals, but do not use it as the source of record. Confirm with Help Scout exactly which fields and date ranges the report includes for your plan and account.
How do we prove the exported archive is complete?
Completeness is shown by reconciliation, not by assuming the script worked. Compare conversation and thread counts per mailbox and status against Help Scout counts taken at a fixed cutoff time. Record every failed request and its retry result, verify attachment counts and file sizes, and check a random sample of conversations against the source by eye. Keep a manifest with hashes for the exported files and store the logs with the archive. These records support your internal review and compliance readiness work, but independent auditors and certification bodies decide whether controls meet a standard. DeployOpen prepares the evidence and does not issue attestations.
Are deleted or spam conversations included in the export?
It depends on the query parameters and on how Help Scout returns deleted or spam items, so confirm this in the current API documentation before you write the export logic. Decide the policy first: whether deleted items are part of the retained record, whether spam is kept for audit or dropped, and who approves that choice. Then filter explicitly and log what was excluded, with counts. Without that record, a later reviewer cannot tell an intentional exclusion from a missing conversation.
What does a fixed-scope export engagement need from us?
A fixed-scope engagement starts with a written scope that names the mailboxes, date range, data types, target system, retention rules and acceptance criteria. You will need to provide administrator approval for API credentials, a named contact for decisions, and access to the target environment. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope. Ask for the deliverables, the reconciliation evidence, the handover documentation and what support is included after the export.
What to prepare on the FreeScout or Chatwoot side before import
An export is only useful once the data can land in a target, so the first decision is the import path. FreeScout's README links a migration service and an API, and Chatwoot provides its own API and self-hosting options. Neither source in this research confirms a direct Help Scout importer, so confirm with each vendor whether either tool accepts Help Scout data as a source before you choose between a built-in migration, a custom API import or a scripted load. Whichever path you take, check it against the exported structure: conversations, threads, attachments and customers must map to the target's objects, and the target's API must accept the attachment and author fields you plan to send.
Next, prepare the containers. In FreeScout, each Help Scout mailbox usually becomes a mailbox in FreeScout, with its own sending and receiving settings, so decide whether the old addresses will keep receiving mail during cutover. In Chatwoot, plan inboxes for each email channel and assign teams and agent access before loading history. Map customers and tags in a spreadsheet first: decide which Help Scout customer records become contacts, how duplicate email addresses are merged, and how Help Scout tags translate into FreeScout tags or Chatwoot labels. Record each mapping in a file your team can review, because mismatched contact identities are hard to undo after import.
Finally, decide how archived threads appear to agents. Imported history can look like live work if it lands in open queues, so choose a status for migrated conversations and keep them out of active assignment rules. Consider whether agents need to see the original sender, timestamps and internal notes, and test a sample conversation with attachments in a staging instance. Confirm the target's attachment size and storage limits with its documentation before the test, since large files are a common cause of failed loads. Agree these choices with the support team in writing so that the import scope, cutover date and rollback plan are settled before the full data set is moved.
How DeployOpen scopes and delivers a Help Scout export
DeployOpen treats a Help Scout export as a scoped engagement, not a one-off download. We agree in writing which conversations, threads, attachments and customers must leave Help Scout, how they will be verified, and where they will land in your own environment before any extraction begins.
How we scope
- Inventory the mailboxes, conversations, attachments and customer records you need to keep, including any Docs content.
- Confirm your Help Scout plan and the Inbox API rate limits that will govern extraction speed and scheduling.
- Agree in writing which data goes to FreeScout or Chatwoot, what stays archived, and who signs off on completeness.
How we build
- Build the OAuth 2 extraction against the Inbox API, with paging and retry logic that respects plan rate limits.
- Test the pipeline on a sample mailbox, checking threads, attachments, customer links and timestamps against the source.
- Document the CSV or Excel reporting export separately, noting what it omits, so reports are never mistaken for a full archive.
How we hand over
- Deliver the exported dataset, the extraction scripts and a reconciliation report comparing record counts and attachment totals.
- Provide runbooks describing how to rerun the export, how to verify a partial run and how to rotate API credentials safely.
- Walk your team through the written deliverables and record the acceptance decision against the agreed scope.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer if you need help after handover.
- Ask for a quote based on your written scope, since DeployOpen does not publish a price list.
