The best exchange depends first on which of three jobs you mean. A built-in grid bot needs an eligible product with clear stop and inventory behavior. Your own order-sending code needs trading API permissions and reliable order-state recovery. A trading journal needs history access, not permission to place or withdraw orders. One venue can pass the first test and fail the third for your exact account, product or retention window. The provider documents linked here were checked September 24, 2026; this is a decision method, not a live benchmark or a profitability ranking.
| Job | Verified examples | Decision test and failure |
|---|---|---|
| Built-in trading bot | Binance bots, Bybit Spot Grid, OKX bot hub | Is the exact spot/futures bot eligible, what stops it, where is collateral, and are individual fills exportable? A green grid-profit tile can hide unclosed inventory. |
| Custom order-sending API | Binance endpoint permissions, OKX tool guidance | Is trading permission separate from transfer/withdraw, and can the bot recover an order with unknown status? Blind retry can double exposure. |
| Read-only journal/API sync | OKX API FAQ, Kraken history guidance | Can the key retrieve the exact fills, fees, transfers and funding for this account and period without placing or withdrawing anything? A clean import can still omit activity. |
Three permissions, three different consequences
For recording, ask for only the permission that retrieves the required private history. For trading, a custom bot needs explicit order placement/cancellation permission. Withdrawal or transfer is neither a prerequisite for analyzing trades nor normally needed for an order-sending strategy. Do not reuse the bot's powerful key for a journal merely to save a minute of setup. Separate keys also let you revoke one tool without interrupting the other.
The labels vary by provider. Binance's Spot API reference distinguishes USER_DATA (private account and trading history) from TRADE (placing/canceling orders). OKX's API FAQ lists Read, Trade and Withdraw; its third-party connection guidance advises one key per tool, trading scope only for tools that place orders, and no withdrawal scope for a trading integration. These labels do not establish that every position-history, funding, bot-wallet or subaccount route needed by a particular journal is available under one read-only key. Do not grant trading permission merely to make journal sync work. If the exact required history cannot be retrieved read-only, use a verified file route for that slice or mark it unsupported. Test the permission and account against a known transaction, not a green connection indicator.
| Scope | Minimum legitimate purpose here | Journal history check |
|---|---|---|
| Public market data | Quotes and product metadata, often no private key | Not enough to recover your trades |
| Private read/history | Orders, fills, account activity and supported cost fields | Potentially appropriate; prove the exact endpoint and period |
| Trade/order management | Place or cancel live orders | Do not grant solely to journal or AI analysis |
| Transfer/withdraw | Move assets or withdraw them | Do not grant for journal or ordinary order placement |
If a tool instead uses an OAuth or broker authorization, examine that consent scope rather than looking for an API-key switch. An API key and an OAuth connection are different mechanisms; “read-only” describes the granted capability, not a universal setup flow. Keep the secret and passphrase out of chats, screenshots and support tickets. Use provider-supported IP restrictions where the tool supplies stable addresses, monitor existing keys, and revoke an exposed key from the exchange before replacing it. Never test permissions by placing an unwanted live order.
The order may exist even when the API call says “timeout”
Suppose a custom bot submits a buy for 0.10 BTC, receives a network timeout, and automatically sends another buy for 0.10 BTC. If the first request actually executed, the account can now hold 0.20 BTC, twice the intended exposure. The numbers are a hypothetical failure rehearsal, not a reported incident. Binance's API documentation explicitly says a request timeout or server-side 5XX can leave execution status unknown; it calls for checking the user-data stream and querying status. The same reference documents 429 rate-limit responses, backoff, and an IP-ban risk after repeated violations. A venue's marketing API label says little about whether your bot handles these states correctly.
The safer design keeps a stable client-side order identifier, an intended-position ceiling and a recoverable log. On uncertain status, stop submitting replacement risk, query the actual order/fill state and reconcile the intended quantity against the account position before another action. On a partial fill, size the next order from executed quantity rather than from the original request. After a reconnect, rebuild state from exchange-side orders and balances; a locally “successful” log line is not proof of a fill. These are engineering controls to test in a documented test environment where available, not a guarantee that a particular API never fails.
Ask the venue and your bot developer six questions before live size: (1) what exact symbol, settlement and margin mode is eligible for this entity? (2) Is there an order ID you can query after timeout? (3) How are partial fills and cancel/replace results represented? (4) What are the current request and order rate limits? (5) What stops new risk after inconsistent state? (6) Can the resulting fills and costs be exported or read by a separate, least-privilege journal connection? A favorable answer to the first five but “unknown” to the sixth is a real reporting trade-off, not a minor documentation issue.
A bot's profit tile is not the whole account result
Consider a grid bot that completes several profitable buy/sell cycles while still holding inventory that has lost value. A transparent review includes realized cycle results + mark-to-market of remaining inventory − fees − relevant funding/borrowing costs, with care not to double-count any fee already included in the provider's number. Assume a hypothetical spot-grid display shows $60 of completed-cycle profit before fees, remaining inventory is $85 below its purchase basis, and total recorded fees are $8. The combined change is −$33 before other cash flow: $60 − $85 − $8. This is illustrative arithmetic, not a measured result from any exchange or customer.
The ledger test is more revealing than a bot ROI screenshot. Save starting base/quote balances; each order and partial fill; trading fees and fee currency; transfers into or out of the bot wallet; remaining base and quote balances at the same valuation timestamp; and, for leveraged products, funding and liquidation-related events. Compare the resulting account change with the provider's bot summary. If one ledger is unavailable, label the whole-account result not verified rather than treating an empty row as zero. Bybit documents behavior when price leaves the Spot Grid range. A list of completed cycles may not represent the whole exposure.
For a futures grid, add the exact contract, margin, leverage and signed funding cash flows. Do not import the spot example as a futures-return formula. If you compare a built-in bot with your own API strategy, hold product, account tier and review period constant, and include orders that never filled. A faster-looking strategy that discards canceled or missed orders from its report is not an apples-to-apples comparison.
A Pionex spot-grid example: which profit are you looking at?
Pionex's own Spot Grid explanation makes the distinction concrete: Grid Profit reflects completed cycles, while coins still held can have an unrealized loss large enough to make the overall investment negative. Releasable Profit is yet another figure—the amount currently movable out of the running bot, affected by its reserved funds and open orders—not a synonym for the result after closing everything. Pionex explains the reserve. A green Grid Profit tile therefore answers neither “should I keep this bot?” nor “how much did this capital earn?”
For a real decision, freeze one bot and one time: record the assets still inside it, their current value, all additions and removals, and the fees already included in the display. Compare the resulting change in capital with that bot's Total Profit view, then ask what happened to the strategy when the held asset fell. Do not add completed-grid profit a second time if it is already in those assets, or subtract a fee twice if it was already reflected in the provider figure. This is a review method, not a forecast that waiting will recover a loss.
The source boundary matters before asking TSB's AI Coach to rank bots. TSB currently recognizes a named historical Pionex spot-order file, but its tested record does not identify which bot placed an order or show the inventory left inside each bot. The current Pionex history-export instructions also do not prove that every generated file matches that tested shape. Without a reliable bot-to-order link and opening/closing asset values, TSB can review the recorded account-level trades but must say per-bot return not verified. A Pionex Futures Grid needs separate position and funding evidence; a spot-order file is not proof of futures-bot coverage.
Does a unified account give you one complete trading history?
No: unified collateral and complete journal coverage are different claims. This is a venue-choice test, not a duplicate of the Binance/Bybit connection walkthrough. Before choosing an exchange for both strategy execution and later AI review, find out whether you can recover a consistent personal record for the exact products and accounts you will use. The outcome may be “usable for spot but not yet verified for my bot's futures wallet,” even if login and an API-key test succeed.
| Where a plausible-looking history can break | Evidence to request before choosing the venue | What a passing result means |
|---|---|---|
| Wrong product or account mode: a spot request says nothing about perps, options or an old account segment. | Record the legal entity, account/subaccount ID and mode, plus every traded product. Query one known execution in each category with the least-privilege history credential. | The sampled surfaces are readable; untested markets are still unknown. |
| Orders mistaken for executions: one partial order can create several fills, and canceled orders can create none. | Match exchange execution IDs and quantities against the order and position change. Check a partial close and a position flip, not only a full-size round trip. | The selected interval's population and grouping can be reconciled without counting an order twice. |
| Costs or internal movements missing: fills, realized P/L, fees, funding and wallet transfers may live in different histories. | Reconcile one known funded derivatives close and, if a bot wallet is used, the transfer in and out. Keep the cost currency and cash-flow type visible. | A net-result claim can be scoped to the covered account and period; a transfer is not profit. |
| Healthy key, truncated window: defaults, pages and retention can omit older fills. | Test the oldest needed trade and an inactive symbol; follow every cursor/page and compare counts and dates with an official export. | An explicit covered date range, not an assumed lifetime history. |
These are not hypothetical API distinctions. Bybit's trade-history endpoint requires a product category, supports a cursor and notes that one order can have multiple executions; its default query window is seven days when neither timestamp is supplied. Bybit's account-mode guide distinguishes older Unified Trading Account versions and says UTA 1.0 kept inverse contracts in a separate account while UTA 2.0 integrates them. Its transaction-log endpoint is a different account ledger from execution history. OKX's account configuration reports both account mode and whether the requesting UID is the main account or a subaccount; OKX documents distinct fills and account-bill routes. These source facts explain why to test separate surfaces. They do not assert that TSB currently imports every named route, bot wallet or historical mode.
For a practical acceptance test, pick a seven-day interval you can inspect in the exchange UI. Include one spot fill, one derivatives close with a fee and funding entry if that is part of your actual trading, and a bot or subaccount transfer if you use one. Record the account ID, market, instrument, exchange execution ID, UTC time, quantity, gross result, fee amount/currency, funding, and balance change. Compare each with the read-only export or API response, then with the journal's imported record. If any field is absent, write not verified, not $0; if a row appears twice in a bills list and an execution list, reconcile its ID and accounting role instead of adding both to P/L. A clean connection status passes only the access test. It does not pass the history-completeness test.
This check changes the purchase decision. If two venues both run the required bot but only one gives your entity and account mode a reproducible record of the trades and costs you actually care about, that is a legitimate reason to prefer it—without inventing a universal “best exchange” ranking. If neither does, use a provider export for the gap and keep the unsupported account slice outside any TSB AI Coach conclusion. The Coach can go deep on the selected recorded history and expose missing evidence; it cannot learn trades that the exchange never supplied.
Choosing a venue without inventing a “winner”
Use a four-gate shortlist. Gate 1: account and country eligibility for the exact spot or derivatives product. Gate 2: the bot or order API actually supports the strategy and its risk controls. Gate 3: a small, already legitimate trading-history sample reconciles across fills, fees, funding and balances. Gate 4: the trader can revoke trading power without losing the independently recorded history. A venue that fails any hard gate is a poor fit for that job, however attractive its generic bot catalog looks.
Compare remaining venues on measured, same-scope evidence: real executed maker/taker mix, order-state recovery, history coverage, wallet accounting and all-in costs. Do not call Binance, Bybit or OKX the fastest, most reliable or most profitable here; no matched live-account panel was run. If only one account provides usable evidence, the answer is “best documented fit for this account,” not “best exchange for everyone.” A sponsor may have a clearly disclosed commercial placement, but cannot buy a favorable editorial verdict or remove a failed gate.
Where TSB's AI Coach fits
TSB's supported-brokers inventory identifies named sync and file routes; it is not a promise that every bot wallet, historic contract, funding line or subaccount is covered. A selectable market is not proof of complete read-only coverage. Choose the exact source, import or connect a small sample, and reconcile one known position and its fees against the exchange before relying on ongoing analysis. The journal connection should not have live trading or withdrawal power. A read-only attached-file inspection is also distinct from a durable journal import.
After that reconciliation, AI Coach analyzes a bounded selection of recorded personal trade history using TSB's evidence lenses and source-derived metrics. Access to Coach itself currently requires Full Access; a free journal is not a free Coach entitlement. A useful question is: “Across my recorded bot-tagged trades in the selected period, did the result after verified, recorded fees differ from comparable manual trades, and which trade groups support that?” It can also examine fee drag, sessions, sizing, exits or data-quality gaps when the sample and required fields are present. Check the answer's account, date range, sample count and cap before treating it as a statement about the whole archive. The trader must actually separate bot and manual cohorts in the record; the Coach cannot infer an absent tag, an unexported wallet transfer or missing funding. A one-off attached CSV may have provisional gross/net field semantics and is not a substitute for a reconciled journal cohort. Coach can explain a supported pattern and a next test, not tune the bot, place orders, predict returns or certify a universal venue winner.
Questions worth asking before committing funds
Can I use one API key for both my bot and a journal? A venue may allow a broad key, but it enlarges the journal's risk surface. Prefer a separate least-privilege history key or appropriate read-only OAuth grant; verify it can retrieve the required private record. OKX explicitly recommends one key per tool.
Does read-only mean complete history? No. It means the tool cannot take prohibited actions under that scope. Endpoint access, retained period, selected account, futures versus spot and bot-wallet transfers are separate coverage questions. Reconcile known trades and balances before an AI or performance claim.
Does a grid bot with positive grid profit make money? Not necessarily for the whole account. Include remaining inventory and actual costs at the same timestamp. A completed-cycle tile can be positive while total equity change is negative, as the worked example shows.
Can AI choose the best bot settings for me? Not from a generic promotional ROI table. A reconciled personal record can support a narrower retrospective question about where a recorded strategy did or did not hold up. It does not make unfilled orders or future market behavior observable.
