Give an exchange API key only the permissions its integration needs, and inspect withdrawal-address management separately from withdrawal execution. A read-only reporting tool should not need authority to place orders or move funds. Disabling withdrawals reduces one risk, but a key that can trade or disclose account history still carries meaningful authority.
Describe the job before creating the credential
Write one sentence describing what the connected application must do: read balances, export a defined history period, manage an approved set of orders, or perform an explicitly authorized funding task. Then map that job to the exchange's current permission list. Starting with every box enabled and removing some later gives the integration broader authority during the period when you understand it least.
Distinguish an account-specific credential from access to public market data. Kraken's spot API-key guide separates private account endpoints from public market endpoints and lists different permissions for funds, orders and history. Other providers use different names and groupings. Treat Kraken as an example of the distinction, not a universal permission schema for every exchange.
Read capabilities rather than a reassuring key label
| Capability | What it can permit | An appropriate question | Risk left even without withdrawals |
|---|---|---|---|
| Read balances or positions | View financial account information | Does this tool need every available balance field? | Sensitive holdings and exposure can be disclosed |
| Read or export history | Retrieve past activity and reports | Can the time range and dataset be narrowed? | Detailed financial records can leave the account |
| Create or modify orders | Make trading decisions through the API | Is order authority genuinely part of this integration? | Unauthorized or erroneous trades can change the portfolio |
| Cancel orders | Remove existing pending instructions | Which orders must the integration manage? | Protective or intended orders may be disrupted |
| Manage withdrawal addresses | Change eligible destinations where supported | Why would a reporting tool need this? | The account's destination configuration can change |
| Execute withdrawals or other funding actions | Move funds under the provider's rules | Is this action explicitly necessary and separately controlled? | Direct loss becomes possible if the authority is misused |
Names such as Safe Bot or Portfolio Viewer are descriptions chosen by a user or provider; they do not enforce those limitations. Inspect the actual grants on the exchange's side. Likewise, read-only is useful only when it accurately describes the enabled capabilities. A screenshot from the integration's marketing page is not a substitute for the current key configuration.
Address management deserves its own check
Kraken's withdrawal-address permission documentation, updated in September 2026, describes a separate permission to add and remove withdrawal addresses. It warns about the combination of that capability with withdrawal authority. This is a concrete reason to review the whole permission set rather than checking one Withdraw switch and stopping there.
The same lesson applies when another provider groups actions differently. Determine whether a key can alter destinations, create internal transfers, operate subaccounts or invoke other funding functions relevant to that provider. Do not assume a category named Trade or Funds means the same thing everywhere. Ask the integration to justify each requested capability in terms of its actual task, then verify that claim against the exchange's own documentation.
A key without withdrawal rights can still cause damage
Trading authority can create unwanted orders, change exposure or generate costs. Read access can reveal balances and transaction history. Cancellation rights can disrupt instructions you intended to keep. None of those risks requires a direct withdrawal request. The Kraken API-security overview lists account information and actions separately, making clear why different grants should be evaluated individually.
This does not mean every integration is malicious. It means the consequence of a faulty or compromised integration follows its real permissions. Separate keys for separate applications make it easier to identify activity and revoke one connection without unnecessarily interrupting another. Keep an inventory of the integration, key identifier, granted capabilities, responsible person and intended retirement date; do not put the secret itself in a shared inventory.
Use network restrictions as an additional boundary
Where supported, an IP allowlist can restrict the origins from which a key works, and expiry can limit its lifetime. Those controls do not replace narrow permissions or secure storage. If the allowed server itself is compromised, its permitted network origin does not make the requests legitimate. Confirm which infrastructure the integration actually uses and how changes are communicated before setting an allowlist.
If a key stops working after a hosting or network change, diagnose the cause instead of immediately removing every restriction. The same applies to API-specific authentication options: they help only when the client supports the provider's requirements. An authentication error is not a reason to disclose the credential in a public ticket or send an unrestricted replacement to an unverified helper.
Protect the secret through setup, logs and retirement
Use the integration's documented secure credential channel and understand how it stores and deletes the secret. Avoid pasting keys into public code, screenshots, ordinary chat threads or logs. A QR code can carry the credential too. The provider's security measures cannot reverse a secret copied into an uncontrolled location; revocation and replacement are different from deleting the visible message containing it.
- Create one key for the defined integration and enable only its necessary capabilities.
- Check read, order, funding and address-management permissions as separate questions.
- Apply supported network and expiry restrictions without treating them as complete protection.
- Record the non-secret key identifier and the person responsible for the connection.
- Verify access through the intended application without granting additional rights merely to silence an unexplained error.
- Revoke unused or exposed keys and review the activity performed while they were valid.
If the key may already be exposed
Use the exchange's verified interface to revoke the affected credential promptly, then review its recent orders, funding actions and configuration changes. Preserve relevant event records without reproducing the secret. Check the connected application's account and hosting environment as well; replacing a key in the same compromised location can expose the replacement. Follow the provider's incident guidance for any suspicious account activity.
The exchange-account security guide covers the surrounding account protections. If someone approaches through chat claiming to fix API access, use the checks in the fake-support guide. For a separate no-account swap, keep order references and payout addresses distinct from exchange API credentials. Knowing an order's details is not a reason for anyone to receive authority over an unrelated exchange account.
FAQ
Which Kraken API-key permissions should I enable?
Map the intended integration to Kraken's current documented capabilities and grant only those it needs. Inspect withdrawal and address-management rights separately rather than starting with all permissions enabled.
What is the difference between an API key and its secret?
The provider's authentication scheme uses credential material to identify and authorize API requests. Treat the required key pair or secret-bearing QR code as sensitive; the label public key does not make the complete credential safe to share.
Why is my Kraken API key not working?
Possible causes include the selected permissions, network restrictions, expiry or the client's authentication support. Diagnose the actual error through verified documentation before removing safeguards or creating a broader key.