An API key lets software access an exchange account within the permissions granted to it. Reading trade history and submitting orders require different capabilities. Connecting a bot should therefore start with a list of the operations it needs, rather than enabling every available permission.

This guide explains how to check that list and prepare access without exposing secrets. Bybit V5 is a documented example of a permission structure. Its field names should not be transferred automatically to another venue or treated as proof that a particular bot supports the integration.

Describe the connection’s job first

Create a short record of the exchange, main account or subaccount, trading product, testing environment, software and machine running it. Write the required actions in plain language: “read trade history”, “retrieve open orders”, or “submit and cancel orders”. This makes an unrelated permission easier to identify.

• Monitoring: the program collects information but should not change the trading state.

• Execution: the program submits orders and checks their status; required trading scopes depend on the product and API.

• Moving funds: transfers and withdrawals are separate actions. If they are outside the agreed workflow, they should not be added merely in case they become useful.

Public market data may be available without access to a private account; check the documentation for the particular method. A program’s need for a quote does not by itself justify account permissions.

Reading permissions: the Bybit example

The Bybit V5 API-key information reference separates readOnly from permissions: 1 means read-only and 0 read/write. Documented scopes include ContractTrade with Order and Position, Spot with SpotTrade, and Wallet with transfer rights and Withdraw; availability also depends on main-account or subaccount context. It describes bound IPs and expiry fields too.

This suggests a useful check: read the key’s overall mode together with its specific scopes. A trading-related label in a list should not be interpreted as permission for every operation. Compare the key information with the requirements of each API method the software needs.

For comparison, Coinbase Exchange documentation separates View, Trade, Transfer and Manage. The same task can have different permission names on two exchanges. Instructions for one Coinbase product also do not replace the documentation for another.

Why “no withdrawals” does not mean “no risk”

A key with trading access can allow operations that change account value. A software error, the wrong instrument or a duplicate order can produce losses without a withdrawal. Alongside Withdraw, inspect internal-transfer permissions and other scopes that are unnecessary for the task.

Consider a hypothetical reporting service that needs history and balances, but whose proposed access also allows order submission. The mismatch is visible before connection: trading was not part of its stated job. Conversely, read-only access may be insufficient for an execution program. The decision follows the required workflow, not one universal set of checkboxes.

A staged connection check

1. Confirm the account and environment. Identifiers, product and connection address must belong to the agreed environment. Demo, testnet and the main account may use different rules and credentials.

2. Check reading. Compare the balances, positions and history visible to the software with the expected account. This check does not require a new trade.

3. Review IP restrictions. Where supported, identify the server’s actual outward-facing IP address and the procedure for changes. A laptop’s address may differ from that of the machine running the bot.

4. Record access ownership and expiry. Record the key’s purpose, responsible person, expiry and protected configuration location without putting the secret in a shared log.

5. Separate the execution check. Successfully reading a balance does not prove that the required order can be submitted. Define a distinct order, response, cancellation and state-reconciliation scenario for an authorised test environment.

The demo-versus-live comparison protocol explains why environments need separate checks. Before testing submission, clarify market and limit order conditions: permission to trade and the expected execution outcome are different questions.

Storage, replacement and revocation

Store the API secret, private signing key and any additional secret phrase in an appropriate protected location. Exclude them from screenshots, recordings, support emails, public repositories and ordinary logs. Inspect even a technical API response for identifiers and access information before sharing it.

For a planned replacement, decide who pauses automated actions, reconciles positions and orders, updates configuration and confirms that old access has been revoked. A new key should not silently leave a second software instance operating. Nor should key revocation be assumed to cancel every exchange order or close a position: those are separate states that require checking.

If a secret has been exposed, obscuring an already published image does not make it confidential again. Use the exchange’s official revocation facilities and inspect account activity. To discuss an integration with New Hope, provide the exchange, product and task description; do not send the key or its secret through the enquiry form.