Exchange API history retention limits which records an endpoint can return, while exports may cover a different period and different event types. Map coverage separately for orders, executions and balance changes, use available official exports for older periods, and preserve the original files with their scope. An empty response beyond a documented lookback boundary does not establish that no activity occurred.
A history import can finish successfully and still leave half a trading year unexplained. The solution begins with a record of what each source can establish, before another request or spreadsheet merge.
Separate retention from the size of a query
Three limits answer different questions. A page limit controls rows returned at once. A request window controls the interval one query can ask about. A retention boundary controls how old an eligible record can be before that endpoint no longer returns it. Splitting an unavailable year into smaller windows does not restore the year.
Start a coverage map for each venue, account or subaccount, environment and product. Include the requested UTC interval, event category, documented historical boundary, status exclusions and source review date. Keep the desired start date even when the available source begins later.
| Record needed | Evidence it supplies | What it cannot establish alone |
|---|---|---|
| Orders and amendments | Submitted instructions, cancellations and lifecycle observations | Every individual execution or cash movement |
| Executions | Filled quantity, price and reported execution fees | Rejected orders and instructions that never filled |
| Account ledger | Deposits, withdrawals, transfers and other recorded balance changes | The full sequence of trading intentions |
| Balance snapshot | Assets or liabilities observed at a point in time | The transactions that produced that state |
The history pagination guide covers traversal inside an available window. Here the prior question is whether the required window and record category are available at all.
Retention can depend on an order's status
There is no universal “exchange API keeps three months” rule. Even one endpoint can apply different eligibility rules to different orders.
For Binance USDⓈ-M Futures, All Orders (GET /fapi/v1/allOrders) excludes orders whose creation time is more than 90 days old. It also excludes CANCELED or EXPIRED orders with no filled trade when creation time plus three days is earlier than the current time. That shorter exclusion concerns creation time, not three days after cancellation. These rules apply to this futures endpoint; they are not a statement about Binance Spot or every export. Binance USDⓈ-M All Orders documentation.
Bybit's V5 order-history endpoint (GET /v5/order/history) separately restricts fully canceled, rejected and deactivated orders to the last 24 hours, while beyond seven days it supports orders with fills. Therefore a long execution record and a long record of unsuccessful instructions are different requirements. Bybit order-history eligibility rules.
These examples were reviewed on 26 October 2026. Check the current documentation for the actual account, product and endpoint before assigning a deadline.
Short-lived order evidence matters when explaining why an instruction failed. Preserve the observed trading mode and status, including any cancel-only or other restriction, alongside the order record. A later collection of fills cannot reconstruct every rejected attempt or the conditions surrounding it.
Ask what an export contains before trusting its date range
An export reaching the beginning of an account can still omit the information needed for a particular review. “History” is a label, not a common schema.
Kraken's export guide distinguishes Trades, Ledgers and Balances. Trades provide execution details; Ledgers include deposits, withdrawals, fees and other balance changes; Balances are snapshots. The guide also says order history cannot be exported directly. Executions can help reconstruct filled order activity, but cannot reveal instructions that produced no execution. Kraken account-history export types.
Record which export was requested, its assets, accounts, fields, timezone and dates. Compare those choices with the actual headers and contents. A file named “annual transactions” does not establish that funding, borrowing, conversions or transfers are included; inspect the product's documentation and rows.
For example, Kraken's export API defaults its start time to the first of the current month. Giving a request an annual description while omitting the start parameter does not request a year. Set the required interval explicitly. Kraken export date parameters.
Longer request allowances need careful interpretation too. Binance's asynchronous futures order, trade and transaction downloads permit a start-to-end span of up to one year. That is a request-span rule, not proof of an unlimited historical archive. Its download-link endpoints also document seven-day link expiration, which concerns access to the generated file rather than the age of its underlying records. Binance futures download request and link rules.
Keep absent columns distinct from explicit zero values. An export without a fee field has not established zero fees; the missing, null and zero field guide explains how to preserve those distinctions during import.
A worked recovery: 183 days, two kinds of completeness
Consider a hypothetical account review from 1 April 2026 through the end of 30 September. The operator freezes the upper boundary at 1 October, 00:00 UTC. All intervals below include their start and exclude their end, so adjoining dates do not count a day twice.
This fictional connector exposes orders, executions and ledger records for the latest 90 days. This is an illustrative contract, not a claim about any named venue. At the frozen boundary, its accessible interval starts on 3 July. There is no existing local archive.
| Recovery stage | Sources now available | Coverage conclusion |
|---|---|---|
| Initial API backfill | 3 July–1 October, all three categories | 90 days collected; 1 April–3 July remains unavailable through this source |
| Export requested | Trades and ledger reports for 1 April–1 September | Request receipts exist; historical coverage has not yet improved |
| Files downloaded and validated | Older trades and ledger reports plus the API backfill | Executions and ledger span 1 April–1 October; older unfilled order evidence is still missing |
The requested period is 183 days. The exports span 153 days, and the API span is 90 days, with a 60-day overlap from 3 July to 1 September. Their union is therefore 153 + 90 − 60 = 183 days. The original unavailable interval was 93 days.
That arithmetic describes intervals, not proof that every event arrived. Validation must still establish that the files cover the correct account and categories, that all required queries finished, and that overlapping records agree. A month with no rows can be a valid quiet month, but it needs a successful scoped collection rather than an assumption.
After those checks, the operator can mark execution and ledger coverage complete for the requested period under the reviewed source contracts. The order audit remains incomplete for the first 93 days because neither export includes unfilled orders. Finding a matching ending balance does not repair that gap. A withdrawal and a deposit of the same amount could both be absent without changing the ending total.
The useful deliverable is three coverage statuses, not one green “history imported” badge.
Validate the bridge between API records and exports
Keep the original downloaded archive and its checksum before normalizing rows. Save the request filters, generation time, download time, file format and importer version beside it. A checksum detects later file changes; it does not authenticate the exchange or establish that the file is complete.
For an asynchronous export, distinguish requested, processing, downloadable, downloaded and validated. Kraken provides separate endpoints to request a report, check its status and retrieve the resulting ZIP archive. An export job identifier alone is evidence of a request. Kraken export request API, export status API, data retrieval API.
Use the overlapping period to check the bridge:
- Match account, product, instrument and event type before comparing rows. A main-account report may not establish a subaccount's coverage.
- Compare execution identities, quantities and fees in their original assets. Use documented identity scope; the trade IDs versus order IDs guide explains why one order can correspond to several fills.
- Reconcile ledger changes against suitable opening and closing snapshots, while retaining unexplained differences. Compare quantities by asset before adding reporting-currency valuation.
- Investigate unmatched records. Check timezones, report cutoffs, late publication, excluded columns and product migrations before declaring either source wrong.
Do not add a fee again simply because it appears in both a fill and a ledger. They may be two observations of the same economic charge. Preserve the relationship between sources rather than adding every numeric column together.
If identifiers or detail are absent, retain the source rows and label the match uncertain. Similar timestamps and amounts are useful investigation clues, not a universal unique key. Avoid editing the only raw file in a spreadsheet that may convert long IDs or timestamps.
Archive before the shortest useful evidence disappears
An archival plan needs separate schedules for order lifecycle evidence, executions and balance movements. Capture important events promptly and use periodic backfills and exports to verify them. Pick a cadence with room for downtime, delayed publication and repair before the relevant retrieval boundary passes.
Creation-time exclusions deserve special attention. Under the Binance futures rule above, an old open order that becomes canceled without fills may already satisfy the three-day age condition. A plan that waits three days after cancellation can therefore lose its recovery path. Preserve observations while managing the order, then verify its terminal state promptly.
Monitor the oldest unarchived eligible period and the last verified boundary for each category. Alert on a shrinking recovery margin, an expired download or an unresolved import. A successful scheduler run says little if the resulting file was never inspected or stored.
Keep raw files and normalized records in access-controlled storage, with another recoverable copy. Preserve account identity without storing API secrets in the archive. Before a migration or account closure, retrieve available history and confirm that the files can actually be read.
Start with the oldest required date and the shortest-lived record category. Download one available export, compare its overlap with the API, and write down exactly which gaps it closes. Leave every other gap visible until evidence resolves it.