What's inside a Bitget account, and the authorized way in

A single Bitget login sits on top of spot trades across more than 550 listed coins (by its own store description), USDT-M, USDC-M and COIN-M futures positions, copy-trade follower ledgers, and Bitget Earn balances. All of it is server-side. All of it is tied to one account. When a team needs that record set inside their own product — a portfolio app, a tax engine, a treasury dashboard — the question is not what the data is, it's the authorized path to read it without holding a credential that can trade or withdraw. That path is what this brief lays out.

Bottom line: most of what a third party wants — balances, the spot and futures order books for one account, fills, open positions and funding — comes back cleanly over signed read-only credentials the account holder issues. A handful of surfaces stay inside the app and we read those a second way. The sections below name each record type, the route we'd take, and what lands in your repo.

Data Bitget keeps per account

These rows reflect the modules the app actually exposes to a logged-in user, named the way Bitget names them.

Authorized routes into the account

Three routes apply here; access for each is arranged with you during onboarding, not asked of you up front.

Read-only signed credentials (user-consented)

The account holder issues a key scoped to read, and we wire the HMAC-signed read calls behind it: balances, spot and futures orders and fills, open positions, funding, deposit and withdrawal history. Effort is low to moderate, and the signing scheme has stayed stable, so durability is high. We walk the holder through creating the key with the right scope and store it under your secrets policy.

Authorized analysis of the app's own traffic

Some surfaces are richer inside the client than over a key — the copy-trade follower view, certain Earn product states, Onchain swap detail. Under the account holder's authorization we capture and document the mobile or web client's request flow for those, and turn it into a documented interface. Effort is higher and the front end can shift, so we plan a re-validation step into maintenance.

Native export

Bitget produces CSV statements for trade and transfer history. It's coarse and batch-only, but it's the right tool for one job: bulk historical backfill that doesn't need to be live.

On Bitget the signed read-key path does most of the real work — balances, spot and futures orders, fills and open positions all return cleanly, and the HMAC scheme hasn't shifted under us. The places it leaves thin, mainly the copy-trade follower view and a couple of Earn states, are exactly where we bring in authorized capture of the app's traffic. Export stays in the picture only for one-time historical reconciliation. We'd recommend building on the read key and treating the second route as targeted, not default.

What you get at handoff

Each deliverable is tied to a real Bitget surface, not a generic checklist:

• An OpenAPI/Swagger spec covering the read endpoints we wire — balances, history orders, fills, positions, funding, transfers.
• A protocol and auth-flow report documenting the HMAC-SHA256 signing chain (the prehash string, header set, timestamp handling) and, where used, the captured client flow for in-app-only surfaces.
• Runnable source for the key endpoints in Python and Node.js, with pagination and rate-limit handling built in.
• Automated tests against a consenting account or sandbox, including signature-generation and pagination cases.
• A normalized schema that folds spot, futures, copy-trade and Earn records into one shape.
• Interface documentation plus data-retention and consent-record guidance for the read-only credential.

Reading orders in code

This is the read-only signed-credential route in practice — a closed-order pull from the spot account. Field names were confirmed during the build; treat it as illustrative.

import time, hmac, hashlib, base64, requests

API_KEY    = "<read-only key the account holder issues>"
SECRET     = "<secret>"
PASSPHRASE = "<passphrase>"
BASE       = "https://api.bitget.com"

method, path = "GET", "/api/v2/spot/trade/history-orders"
query = "symbol=BTCUSDT&limit=100"
ts = str(int(time.time() * 1000))

# prehash = timestamp + METHOD + requestPath + "?" + queryString + body
prehash = ts + method + path + "?" + query            # body empty on GET
sign = base64.b64encode(
    hmac.new(SECRET.encode(), prehash.encode(), hashlib.sha256).digest()
).decode()

headers = {
    "ACCESS-KEY": API_KEY,
    "ACCESS-SIGN": sign,
    "ACCESS-TIMESTAMP": ts,
    "ACCESS-PASSPHRASE": PASSPHRASE,
    "Content-Type": "application/json",
}
r = requests.get(f"{BASE}{path}?{query}", headers=headers, timeout=10)

# response (trimmed): orderId, symbol, side, priceAvg,
#                     baseVolume, feeDetail, cTime, status
for o in r.json()["data"]:
    print(o["cTime"], o["symbol"], o["side"], o["baseVolume"], o["status"])

The same signing block fronts the futures endpoints (orders-history, fill-history) — only the path and query change, which is why the normalized layer sits one level above this.

What teams build with it

• A multi-exchange portfolio tracker syncing a user's Bitget balances and open positions next to other venues.
• A tax or accounting tool pulling full spot and futures trade history plus deposit and withdrawal records for cost-basis.
• A copy-trade analytics product attributing follower profit to the elite traders they mirror.
• A treasury dashboard watching margin and liquidation distance across USDT-M and COIN-M positions in near real time.

Consent, custody and where regulation sits

Crypto-exchange account data isn't inside the scope of traditional open-banking or account-aggregation regimes, so the dependable basis here is the account holder's own authorization — the read-only key they issue, or their consent to have the client's traffic documented. That consent is scoped, logged, and revocable: revoke the key and the access ends.

For the European market, Bitget is a crypto-asset service provider under MiCA. ESMA has set the MiCA transitional period to end on 2026-07-01, after which providers serving EU clients need authorization; public reporting in late 2025 placed Bitget among exchanges still pursuing a license rather than holding one, under what it describes as a compliance-first approach. None of that changes the integration basis, which is the consenting user — it does mean we keep the build aligned with read-only, data-minimized scope. We hold trade and withdrawal permissions off, keep consent records, and work under NDA where the engagement calls for it.

Build notes we plan around

Two things specific to Bitget shape how we scope the work:

• Wallet hierarchy. Balances span spot, futures and margin wallets, and the unified-account and sub-account structure means a coin can show in more than one place. We model that hierarchy explicitly so a balance sync neither double-counts nor drops a sub-account.
• Copy-trade coverage gap. Per Bitget's Elite Trading API guide, the elite credential reaches futures copy trading but not spot. We don't assume one credential covers everything — futures follower data comes over the signed key, and spot copy-trade follower records are mapped through authorized client capture.
• History windows and rate limits. The history endpoints page and rate-limit, so a one-time historical backfill and an incremental sync are built as separate paths, designed around cursor pagination and request windows rather than one wide range request.

How the work is priced

Source-code delivery starts at $300, billed only after the working integration is in your hands and you're satisfied with it — you receive runnable source for the signed read endpoints, the OpenAPI spec, the auth-flow report, automated tests and interface docs, yours to run on your own infrastructure. If you'd rather not host anything, the pay-per-call hosted API is the other model: we run the endpoints, you call them and pay per call, with nothing upfront. Either way the build runs on a one-to-two-week cycle. Tell us the account surfaces you need and we'll scope it — start the conversation here.

App screens referenced

Screens from the Bitget Play listing we looked at while mapping the surfaces above.

What was checked, and when

This mapping was put together against Bitget's own request-signing reference and history-order documentation, its Elite Trading API guide for the copy-trade nuance, and public reporting on its MiCA position. Primary sources opened:

• Bitget request-signing reference (HMAC-SHA256 header scheme)
• Spot history-orders endpoint documentation
• Elite Trading API guide (futures copy trading)
• Reporting on Bitget's MiCA / Europe position (late 2025)

Mapped by the OpenBanking Studio integration desk · June 2026.

Where Bitget sits among comparable exchanges

Same integration bucket — each holds per-account records a unified view would combine. Listed for context, not ranked.

• Binance — spot, futures and margin balances with order and funding history behind one account; a frequent second source in multi-exchange syncs.
• OKX — spot, perpetuals and Earn positions over a similar signed-request model, often integrated alongside Bitget for cross-venue views.
• Bybit — derivatives-heavy account with positions, fills and funding records that feed the same risk dashboards.
• KuCoin — broad spot listing plus futures and lending balances that map onto the same normalized schema.
• Kraken — spot and futures records under a regulated operator, common in tax and accounting integrations.
• Coinbase — retail spot balances and transaction history widely pulled for portfolio and compliance tools.
• Crypto.com — exchange and app balances plus card-spend records that some unified views combine with exchange data.
• MEXC — wide altcoin spot and futures listing whose order history shares the fields integrators normalize.

Questions integrators ask about Bitget

Can you pull both spot and futures history from one Bitget account?

Yes. Spot orders and fills, plus USDT-M, USDC-M and COIN-M futures positions, orders and funding records, all come from the same authenticated account, and we normalize them into one schema. The wallet split between spot, futures and margin is modeled explicitly so balances do not double-count or go missing.

Does copy trading data arrive through the same route as my own trades?

Not entirely. Per Bitget's Elite Trading API guide, the elite-trader credential covers futures copy trading but not spot. So we read futures follower and elite records through the signed read key, and map spot copy-trade follower data through authorized capture of the app's own traffic.

How do you read the data without holding a key that can move my funds?

The read-only key is created with trade and withdrawal permissions switched off, during onboarding, with you. The credential we hold can query balances, orders, fills and positions and nothing else. Every call is logged and the permission scope is written into the handover docs.

Which Bitget records are hardest to reach, and how do you handle them?

The copy-trade follower view, some Earn product states such as Shark Fin and Dual Investment, and Onchain swap detail tend to live inside the app rather than on the signed read surface. We document those from the client's own traffic under your authorization and fold them into the same output.