Three checkpoints in this guide
Follow the full walkthrough in order, or jump directly to one of its main sections.
Bitget export coverage is broader than TSB import coverage
Bitget’s website can generate Transaction History, Order History, and account statements. Its Order History selector includes Spot, Margin, Futures, CFD, Onchain, OTC, Convert, Crypto Loans, Earn, and Voucher records. That does not mean every export is the same schema or that every category is a verified TSB trade import.
Choose the Bitget dataset by job
| Dataset | What it includes | TSB Full Access |
|---|---|---|
| Spot order details / fills | Pair, base/quote asset, direction, price, amount, total, fee, fee coin | Reviewed positive import |
| Spot Order History | Order ID, type, pair, direction, requested/executed quantity, average price, volume, status | Reviewed positive import when the exact schema matches |
| Spot transaction ledger | Executed spot movements with account and execution identity | Reviewed positive import |
| Futures position/transaction files | Position or cash-flow evidence | Current corpus proves guardrails, not general native futures support |
| Deposit/withdrawal history | Wallet movements and transfer identity | Reconciliation only; blocked from creating trades |
| Account statement PDF | Asset overview or ownership | Control evidence, not a trade CSV |
The current Bitget export screens
Use the Bitget website. On the Data Export page choose Within 6 months or All time, select the account, dataset type, date range, and available file format, then choose Generate. When generation completes, choose Refresh → Download.
The order-page route is different: open the order page, choose the product from the left-side menu, open Order history, apply product/pair/time filters, then choose Download. Select time range, pair, format, and included order information before generating the file.
Bitget documents a maximum selected range of two years for transaction and order history. A Within 6 months request can include up to 10,000 records. Split active accounts into smaller UTC windows before import so a row cap cannot hide activity.
Generation, download, and statement limits
For Transaction History, Bitget currently documents as many as 100 exports per month. After choosing the account, date range, and pair, select Generate; the platform notifies you when the file is ready, and the download link remains valid for seven days. Preserve the request scope before generating because the downloaded filename may not contain enough account context.
The Asset Overview statement is a PDF snapshot for one selected date, not a historical-range execution file, and Bitget currently says it supports data from July 18, 2025 onward. The separate Account Ownership statement can include UID, KYC details, legal name, identity-document information, nationality, and residence. It is not needed for journal import; store it separately and do not attach it to a trade batch.
Before downloading, write down the requested scope
Record the Bitget account, product, dataset, pair filter, UTC start/end dates, and requested file format. The left-side product selector changes the meaning of the export: Spot Order History is not a Futures position report, and neither is a deposit/withdrawal ledger.
When the file is ready, verify that its first and last timestamps match the request and that an active account did not stop exactly at 10,000 rows. Keep the generated archive intact as evidence, but extract it to a separate folder and upload only one CSV at a time.
Supported spot workflow
- Export: choose Spot and export a populated order-details/fills or Order History CSV. If fees must be verified, include the exact spot transaction ledger rather than a PDF statement.
- Import: open TSB Journal → Import trades, upload one extracted, untouched CSV, and confirm that TSB identifies a Bitget spot profile.
- Reconcile: compare pair, direction, executed quantity, average/fill price, order status, fee amount and fee coin, UTC period, and the number of fully executed orders.
- Review: inspect partial fills and duplicates, attach the Bitget account and setup context, then mark the batch reviewed.
Spot acceptance checks
- The preview identifies a reviewed Bitget spot profile rather than a generic CSV.
- Executed quantity and average/fill price are populated; requested order quantity is not substituted.
- Only filled quantities enter the lifecycle; cancelled remainder is retained as order evidence.
- Fee amount and fee coin are both present or explicitly marked unavailable.
- One order with several fills does not become several unrelated trades.
- Deposit, withdrawal, Earn, voucher, loan, or Convert rows remain outside trade P&L unless an exact reviewed profile proves otherwise.
Bitget futures: what to do today
Export the native futures evidence and keep it unchanged, but do not assume that uploading any Futures CSV will create journal trades. The current reviewed corpus detects empty position-history and transaction-ledger templates and rejects them with an exact explanation. It also blocks a ZIP containing several different Bitget datasets until the archive is extracted and one file is selected.
If the futures file is populated but does not match a reviewed positive profile, stop at the preview. Do not relabel columns or remove rows to force acceptance. Preserve the raw export, the selected Bitget product/account/window, and the preview message for a schema review. Until that exact variant is proved, use manual journal entries or a separately reviewed generic closed-trade template; do not advertise the native file as supported.
How to reconcile futures while the native guardrail remains
Keep the Bitget futures export as the authoritative source package. Record the number of closed positions, gross realized P&L, trading fees, funding, and transfers for the period. If manual journal entries are required, enter only closed lifecycles that can be proved from the source and attach the raw-file reference. Do not infer missing entry prices from ending P&L or treat a cash-flow ledger as fills.
This temporary route preserves an auditable bridge without making a false parser-support claim. When a populated native variant is reviewed later, import it into a separate test batch and compare identities before replacing any manual records.
What a future native-support decision must prove
A populated file is not sufficient by itself. A support review must prove stable position or execution identity, contract and settlement asset, side, size, entry and exit timestamps, price semantics, fee asset, funding treatment, partial-close behavior, and duplicate handling across overlapping exports. Until fixtures cover those cases and the parser fails closed on non-trade variants, the production promise remains spot-only.
Final acceptance checklist
- The export came from the website and the selected account/product is recorded.
- The file contains fewer than the relevant cap or the period was split before the cap.
- The raw ZIP is preserved, but only one extracted CSV is uploaded at a time.
- The preview identifies an exact reviewed Bitget spot profile.
- Executed quantity, average/fill price, status, fee, and fee coin reconcile.
- Futures and non-trade ledgers remain guardrails rather than inferred trades.
Bitget-specific failure modes
- Web vs app: account-data export is web-only.
- 10,000-row cap: a six-month window may still truncate an active account.
- ZIP bundle: several CSV families cannot share one automatic mapping.
- Empty futures template: valid headers contain no closed positions or transactions.
- Order requested vs executed: requested amount is not the fill quantity.
- Fee coin omitted: a fee number without its asset cannot reconcile net P&L safely.
Official screen checked
Bitget: How to Export Your Account Data, including the Data Export and order-page flows.
