“Read-only” describes what an API key can do to the account. It does not describe the sensitivity of what the key can reveal.
For a portfolio or tax tracker, the correct exchange key should be unable to place orders or withdraw assets. It can still expose balances, deposit and withdrawal history, trades, open positions and the timing of your activity. Binance explicitly warns that read-only access may expose a full transaction history and could support targeted social engineering.
My judgment: connecting a reputable tracker with a narrowly scoped read-only key is a reasonable trade for automated records. Reusing a trading key, enabling withdrawals, or treating the secret as harmless is not.
Permissions are the security boundary
An exchange API key usually consists of an identifier and a secret. The secret authorizes requests without a normal interactive login. The permissions attached to it decide whether those requests can read data, trade, or withdraw.
CoinTracker says it requests read or view access for exchange syncing and never write, trade or transfer access. Koinly says it typically needs read-only access and does not need withdrawal permission. Kraken’s tax-software guidance lists query permissions such as funds, closed orders, trades, ledger entries and data export.
Those statements describe the intended configuration. The exchange screen is where you verify the actual one.
| Permission | Needed for a portfolio/tax tracker? | Risk if enabled |
|---|---|---|
| Read balances and history | Usually yes | Exposes financial activity and holdings |
| Place or cancel trades | No | Can alter the account and create losses even without withdrawal |
| Withdraw funds | No | Can move assets out of the account |
| Manage users, addresses or security | No | Can weaken account controls or persistence |
“No withdrawal” is necessary, not sufficient
A key that can trade but not withdraw can still be dangerous. An attacker may use illiquid markets, unwanted positions or leveraged products to transfer value indirectly or destroy it. Binance’s own permission guidance says a read-only dashboard does not need trading or withdrawal access.
The privacy risk remains even when every write permission is off. Exact holdings can make a phishing message more convincing. Deposit and withdrawal history can link exchange activity to public blockchain addresses. Open-position data can reveal when a holder is vulnerable to market moves.
Read-only should therefore mean cannot spend, not safe to publish.
A seven-step connection process
- Reach the tracker and exchange through saved bookmarks. Do not create keys after following a search ad, direct message or “support” link.
- Create a dedicated key for one service. A key named after the tracker is easier to audit and revoke. Do not reuse a bot or trading key.
- Enable only the exact query permissions required. Leave trading, withdrawal and account-management permissions off.
- Check network restrictions carefully. IP allow-lists can be valuable, but some cloud trackers state that they do not use a fixed IP. Do not disable a restriction blindly; understand the vendor’s architecture first.
- Transfer the key once. Do not paste it into notes, email it to yourself, photograph it or share it in chat.
- Verify the connection, then revisit the exchange permission screen. Confirm that no permission changed during setup.
- Record a review date. Revoke keys for services you no longer use and rotate a key after any suspected exposure.
OAuth is different, but still deserves review
Some integrations redirect you to the exchange and ask you to authorize access through OAuth rather than copying an API secret. CoinTracker identifies Coinbase as one of its read-only OAuth connections. This reduces secret-handling mistakes, but the permission grant still deserves the same questions: what data can the service read, how long does access persist, and where can it be revoked?
What to do after a suspected leak
Revoke the key at the exchange first. Deleting a connection inside the tracker may not revoke the credential at its source. Review the exchange’s API activity, open orders, positions, withdrawal allow-list and recent security events. If the leaked key ever had trade or withdrawal permission, treat the incident as an account-security event rather than a privacy leak.
A portfolio tracker should never ask for a seed phrase, private key or hardware-wallet PIN. Public addresses and extended public keys can support watch-only tracking; they do not authorize spending. If a service asks for signing secrets, stop.
For a broader import comparison, see wallet address vs API vs CSV. If you are deciding whether a tracker deserves access at all, start with what portfolio trackers know and miss.
Use this security test inside the wider portfolio tracker selection framework; convenience never justifies write or withdrawal permissions.
