Connecting an exchange account to an outside application takes a few seconds on a single screen. That speed creates a false impression: the decision feels as small as the action. In fact, the permissions granted on that screen define, permanently, what the application can do inside your account.
This post explains what the permission checkboxes mean when you create an API key, and which of them a Finbula connection actually needs.
Three permissions, three different risks
Most exchanges split API key permissions into at least three groups:
Read. Balances, open orders, trade history and positions can be read. Nothing in the account can be changed. This is the only permission required to monitor a portfolio, see its allocation, and produce analysis on top of it.
Trade. Orders can be placed and cancelled. Funds do not leave the account, but they move within it: one asset can be sold and another bought. This is the permission required if you want an automated strategy to act for you.
Withdrawal. Funds can be transferred out of the account to another address. Of the three, this is the only one whose consequences cannot be undone.
The difference between them is not technical, it is consequential. A leaked read-only key is a privacy problem; a leaked trade key can cause loss; a leaked withdrawal key can cost you the assets themselves.
Finbula connections never request withdrawal permission. That limit does not change in any mode: not for monitoring, not for bots.
Answer this before the checkboxes: monitor, or run?
The real decision comes before the permission screen.
If your goal is to see your portfolio in one panel, follow allocation and profit/loss, and read market and analysis screens next to your own positions, then a read-only key is enough. Granting trade permission adds nothing in that scenario; it only enlarges the blast radius.
If your goal is to subscribe to automated bots and let them place orders on your behalf, trade permission is required. That is a deliberate choice, and a reversible one: a bot can be stopped, a connection can be removed, and a key can be revoked on the exchange.
A practical pattern: create two separate keys. One read-only, connected permanently. One with trade permission, active only while you are actually running a bot. That way “I want to watch” and “I want to run” never end up hiding behind the same key.
Four checks while creating the key
1. Keep the permission set as narrow as possible. Exchange key-creation screens often arrive with several permissions pre-enabled. Turn off every box you do not need. The permission left on “in case I need it later” is the one that leaks most often.
2. Use IP restriction if it is offered. Most exchanges let you limit a key to specific IP addresses. That prevents a leaked key from being used from anywhere else. If the service you are connecting publishes fixed egress IPs, enter them.
3. Label the key with its purpose. Exchange key lists include a name field. Something explicit like finbula-readonly removes the “what was this key for?” question six months later. An unnamed key cannot be revoked with confidence, because you cannot tell which one you are revoking.
4. Remember the secret is shown once. On most exchanges the API secret is displayed only at creation time. Save it in a password manager. Do not screenshot it, do not paste it into a chat app, do not email it to yourself.
After the connection exists
Creating a connection and forgetting about it is riskier than not creating one. Roughly every three months, review:
- Which keys are still active? Revoke, on the exchange, the keys you created to try something and never used again.
- Do the permissions still match the need? If you stopped running bots, trade permission is now sitting there for nothing.
- Is there any activity you did not expect? Compare the exchange’s own trade history with what the application shows. A gap between the two records is the first thing worth investigating.
On the Finbula side you can remove a connection from the panel whenever you like, and the related data access ends when you do. The key itself, however, keeps living on the exchange; the actual revocation happens there. Do not treat the two steps as substitutes for each other.
In short
Granting a permission is reversible, but it holds until it is reversed. The question to ask while creating a key is not “do I trust this application?” but “what is the least permission this application needs to do this job?”
Read is enough to watch. Trade is required to run, and you are the one who enables it. Withdrawal is not required in any scenario.
