HubSpot Data Export Limits: Row Caps, Column Ceilings, and Warehouse Workarounds

HubSpot data export limits catch most teams at the worst possible moment, usually during a board deck deadline or a migration project with a hard cutoff date. The export button in the UI looks simple: pick a view, click export, wait for an email. Underneath that simplicity sits a set of row caps, column ceilings, rate limits, and quiet data omissions that only surface once a dataset grows past a few thousand records. Understanding those limits before you hit them saves hours of troubleshooting a file that looks broken but is actually behaving exactly as documented.

This piece covers the mechanics of HubSpot’s native export system, from the UI and the CRM Exports API, and where teams typically get stuck. It also covers what gets left out of a standard export even when nothing appears to fail, and what the realistic paths look like once exports stop being a reasonable way to move data.

UI Export Limits for Rows, Columns, and Daily Volume

HubSpot’s in-app export tool enforces limits at three layers: how often you can export, how many rows fit in a single file, and how many columns a format can hold. Each layer fails differently, and confusing one for another is a common source of “why is my export broken” support tickets.

On frequency, an account can run up to 300 exports in a rolling 24 hour window, with a maximum of three running at once. Anything beyond three queues automatically rather than erroring out. Row limits kick in separately: CSV and XLSX exports beyond one million rows, or XLS exports beyond 65,535 rows, get split into multiple files delivered inside a ZIP archive. Large exports can take a few hours to process, which is normal rather than stuck. Any CSV file larger than 2MB gets automatically zipped regardless of row count.

Column limits vary sharply by format, and this is where things get quietly destructive. XLS files cap at 256 columns and XLSX files at 16,384. If a request includes more columns than the format supports, HubSpot does not throw an error. It drops the extra columns silently, so a report that looks complete can be missing entire fields with no warning.

FormatRow cap before split/ZIPColumn capFile-size auto-zipDownload link expiry
CSV1,000,000 rowsNo documented limit (practical ceiling around 250)Files over 2MB30 days
XLSX1,000,000 rows16,384 columnsRow-based ZIP split only30 days
XLS65,535 rows256 columnsRow-based ZIP split only30 days

HubSpot’s own documentation recommends CSV for any export with a large number of properties, since CSV carries no documented column ceiling. Third-party guidance from vendors working with large HubSpot accounts describes a practical limit closer to 250 columns per CSV before exports slow down or time out, even though no hard cap exists in HubSpot’s own docs. The same 250-column-style ceiling shows up when exporting data from other CRM platforms, where wide objects hit similar processing walls regardless of vendor.

The export source matters as much as the format. A list or table view export captures exactly what’s visible in that view, filters and columns included. Board views for deals, tickets, and custom objects use a separate “Export view” option. Static lists export a frozen snapshot that never reflects later changes, while active lists reflect live membership. Report exports only pull unsummarized table data, not the charts, and that data is aggregated rather than raw record-level, so it rarely works as a pipeline source. Association columns default to a maximum of 1,000 IDs per column unless you choose the “All associated records” option available in CSV exports.

CRM Exports API Behavior and the Async Job Flow

Everything the UI does manually, the CRM Exports API does programmatically, with a tighter rate limit and a different failure surface. Paid accounts get up to 30 export jobs in a rolling 24 hour period, and only one runs at a time. Additional requests queue rather than reject outright.

The API flow runs in three steps: a `POST` request to the async exports endpoint starts the job with a file format, object type, export type, and any filters; a `GET` request against the task status endpoint polls for one of four states (pending, processing, complete, or canceled); once complete, that response includes a signed download URL.

That signed URL stays valid for only five minutes after the job finishes, with no additional authorization required while it’s live. On a slow connection, or in an unattended script pulling a large file, five minutes is not always enough. The fix is to re-issue the status `GET` request, which mints a fresh URL.

Custom objects need their `objectTypeId` rather than a plain object name, retrievable through the schemas endpoint. Association handling has its own quirks. Up to four associated object types can attach to a single export request. Primary display property values, like a company’s name, come through automatically when exporting exactly one associated object, but default to false once you export more than one, unless the include flag is set explicitly. Association labels, the descriptive relationship tags like “Buyer” or “Decision Maker,” only became available in API exports after the February 2025 rollup. Before that, exports returned generic record IDs with no relationship context. Each row also defaults to a cap of 1,000 associations per object type, overridable with a dedicated parameter.

The API’s `VIEW` export type mirrors an index page and supports search-style filtering with AND logic within a group and OR logic across groups. The `LIST` type needs the list’s internal ILS ID rather than the ID shown in the UI, which trips up first-time API users. Both share the same row and column ceilings as UI exports, since the underlying export engine is the same one.

Format Quirks That Corrupt Data Without an Error Message

A file that opens with garbled accented characters or scrambled Notes fields has not necessarily hit a HubSpot bug. It has usually hit an Excel encoding mismatch. HubSpot exports CSVs in UTF-8, but Excel’s default behavior on a double-click is to guess the encoding, and it frequently guesses wrong on accented characters or special symbols.

The reliable fix is to avoid opening the file by double-click. Import it instead through Data, then Get Data, then From Text/CSV, setting the encoding to UTF-8 and the delimiter to comma explicitly. That option occasionally goes missing in the browser version of Excel, so switching to the desktop app resolves it. Once cleanly imported this way, re-saving as CSV UTF-8 lets colleagues open the file directly afterward.

Long text fields carry their own risk. Notes and other free-text properties sometimes contain internal line breaks, and if a downstream tool mishandles quoting during import, those breaks get misread as new row boundaries. One record can end up looking like several broken rows. One habit prevents a much larger headache later: always keep the HubSpot Record ID column in any export destined for re-import. Without it, a re-import creates duplicate records instead of updating the ones that already exist.

What Standard Exports Leave Out Entirely

A HubSpot export can complete successfully, contain exactly the rows and columns expected, and still be missing information that matters. Property history is the clearest example. It is never included in a standard record export, in the UI or through the API, and requires a dedicated export tool reached through Settings, then Properties, then the export option on a property. That dedicated tool only exports one property across every record, not one record’s full history across every property, so reconstructing a complete change log for a single deal takes real assembly work.

Retention limits compound the problem. Contact properties keep up to 45 revisions, while company, deal, ticket, and custom object properties keep up to 20. Once a property has changed more times than that cap allows, the earliest changes are gone regardless of when you export. Programmatic access through the standard objects API, using parameters like `propertyMode=value_and_history` or `includePropertyVersions=true`, pulls history without the export-specific gaps but still respects the same revision caps.

Deleted and archived records disappear from exports by default too. Deleted contacts, companies, and deals move into a recycling bin marked as archived rather than being purged immediately, but a standard export or API read only returns active records unless the archived flag is set true explicitly. After 90 days the recycling bin empties permanently. Teams that need a durable record of deletions generally query with the archived flag on a schedule or set up a webhook listener to catch deletion events as they happen.

Association labels sit in a similar gap. Before the February 2025 API update, exports only returned generic associated record IDs, with no way to see whether a contact was tagged as a decision maker or an influencer on a given deal. That context now exists in API exports when requested explicitly, but it still has to be configured as a label in the data model before it appears in any export.

Working Around Row and Column Ceilings

Most teams hit the column ceiling before the row ceiling, since HubSpot accounts accumulate custom properties faster than contacts. The most direct workaround splits a wide export into logical passes, one for core properties and a second for extended custom fields, merged downstream using the Record ID as the join key. That sidesteps the practical CSV ceiling without needing tooling beyond a spreadsheet or a basic script.

Filtered exports solve a related problem. Building a dynamic or static list as a pre-filter limits the export to only the segment needed, whether that’s deals updated in the last seven days or contacts created this quarter. This keeps files under the row thresholds and turns one enormous export into a repeatable, incremental habit. When an export does cross the row threshold anyway, HubSpot’s automatic ZIP splitting handles the mechanics, but reassembly is left to you.

Not every large pull needs to go through the Exports API at all. The CRM Search API supports cursor-based pagination through the `after` parameter, retrieving records in pages rather than generating a file. For continuous or near-real-time pulls, this sidesteps the 30-exports-per-24-hour ceiling entirely, since pagination calls fall under HubSpot’s general API rate limits instead of the export-specific quota. This path suits teams with existing engineering capacity more than a marketing operations team looking for a quick CSV, since it means handling retries, rate-limit backoff, and schema drift.

Third-Party ETL Tools and Warehouse Routing Patterns

Once exports become a recurring task rather than an occasional one, most teams stop building around the Exports API and start looking at dedicated ETL platforms. These bypass the export button and its rate limits entirely, connecting through HubSpot’s API on a schedule and handling field mapping, filtering, and incremental syncing without manual intervention.

Fivetran separates current-state tables from dedicated history tables, so property history for companies or deals lands in its own continuously synced table rather than staying subject to HubSpot’s revision caps once captured. Delete detection varies by object type: webhook-based for contacts and deals when connected through the native app, daily re-sync for others, and no delete capture at all for invoice and subscription tables. Airbyte’s connector offers server-side and client-side incremental filtering plus a configurable lookback window for property history changes, though it still operates within HubSpot’s normal rate limits. Skyvia leans toward a no-code audience, with scheduled field-mapped pipelines and a free tier covering 10,000 records a month before paid plans begin. None of these tools are exempt from HubSpot’s underlying API constraints. They manage those constraints for you instead of leaving you to script it yourself.

Getting data out of HubSpot is only half the job. The other half is deciding where it lands and how fresh it needs to stay. A custom-built pipeline using direct API calls gives engineering full control over pagination and loading logic, but it also means owning every schema change HubSpot makes going forward, and a renamed object can silently break a homegrown pipeline. An ETL vendor absorbs that maintenance work for a subscription fee. All-in-one platforms bundle ingestion, storage, a semantic layer, and dashboards together, so HubSpot data becomes queryable within a day or two rather than after months of infrastructure work, a pattern covered in more depth in this look at what fragile ETL pipelines actually cost teams over time.

For teams that want to skip the export-and-load cycle for reporting purposes, a direct connector into a BI tool reads HubSpot data live rather than depending on a warehouse hop. The Power BI Connector for HubSpot works this way, pulling CRM data straight into Power BI reports without routing through CSV exports or a separate warehouse layer first. That’s a meaningfully different approach from either manual exports or a full ETL-to-warehouse pipeline, since it removes the export step from the reporting workflow instead of just working around its limits.

Cost and governance differ sharply too. Native HubSpot exports are free but tied to reporting features gated behind higher tiers, since custom reports require a Professional plan and custom objects require Enterprise. A dedicated warehouse setup ranges from roughly $79 a month for a lightweight ETL-only tool up to several thousand dollars a month for a full stack combining an ETL vendor, warehouse, transformation layer, and BI tool, plus a data engineer to maintain it.

Common HubSpot Export Failure Modes

Most export problems reported in HubSpot’s community forums turn out to be documented behavior rather than bugs.

SymptomLikely causeFix
Large export appears stuck or failedLarge jobs can take hours and get delivered as multiple filesWait for processing; check for a multi-part ZIP before assuming failure
Columns missing from an XLS or XLSX fileExport exceeded 256 or 16,384 column ceiling and was silently truncatedSwitch to CSV or split into logical column groups
Custom property absent from an exportProperty was not added as a visible column in the source viewAdd the property to the view, or use an all-properties export
Row counts look stale or incompleteExported from a static list snapshot instead of an active listConfirm list type before exporting
Property history missingStandard exports never include history by defaultUse the dedicated property history export tool or history API parameters
Garbled characters in ExcelExcel guessed the wrong encoding on double-clickImport via Data > Get Data > From Text/CSV with UTF-8 set explicitly
Re-import creates duplicate recordsExport was missing the HubSpot Record ID columnAlways include Record ID in exports intended for re-import
Signed download URL stops workingFive-minute expiry lapsed before download finishedRe-issue the status GET request for a fresh URL
Deleted records missing from a pullStandard reads default to active records onlyQuery with the archived parameter before the 90-day purge window closes

Deciding When Exports Stop Being the Right Tool

There is no fixed record count where exports become the wrong choice, but a few signals show up together once a team outgrows them. One-time or occasional pulls, single-object analysis with no need to join against other systems, and a lack of engineering bandwidth are all reasonable arguments for sticking with manual exports or filtered lists.

The calculus shifts once exports start happening weekly instead of monthly, once column counts creep toward format ceilings often enough that chunking becomes routine, or once someone in finance needs an answer spanning HubSpot and billing data at once. HubSpot’s report builder has no way to calculate cohort retention across systems or attribute revenue to a channel tracked outside the CRM. Those questions require joining data HubSpot was never designed to hold in one place. That is the point where routing to a warehouse, or connecting reporting tools directly, stops being a nice-to-have and becomes the only way to get a real answer.

Frequently Asked Questions

How many records can I export from HubSpot at once?

CSV and XLSX exports handle up to one million rows before HubSpot splits the output into multiple files delivered as a ZIP. XLS exports split at a lower threshold of 65,535 rows, consistent with that format’s older technical limits.

Why did my HubSpot export lose some columns?

XLS exports cap at 256 columns and XLSX exports cap at 16,384. When a request exceeds either limit, HubSpot removes the extra columns without an error message. Switching to CSV, which carries no documented column limit, avoids this.

Does a HubSpot export include property change history?

No. Standard exports never include property history. It requires a separate export tool accessed through property settings, and the retention window caps at 45 revisions for contacts and 20 for other object types.

What happens to deleted HubSpot records during an export?

Deleted or archived records are excluded from exports by default. They remain recoverable in HubSpot’s recycling bin for 90 days, after which they are permanently removed, so preserving deletion history requires querying archived records before that window closes.

M
Author
Metrica Software Team
Share