出典確認済みリサーチ: Kraken

Verified source facts

1. Kraken describes API keys as the API equivalent of an account username and password and says secrets must not be stored unencrypted. 2. Kraken's creation guide separates query, trading, funding, ledger, export and WebSocket permissions. 3. Kraken's example says a trading integration would normally need modify and cancel permissions but almost certainly not Withdraw Funds. 4. Kraken documents IP whitelisting, key expiration, API-key 2FA, regular rotation and deletion of keys that are no longer relevant.

Comparison at a glance

1. API-key safety step: Official entry

An API key is a credential boundary, not a convenience toggle. The official entry step concerns Kraken Pro Settings and API page. Begin only from the official Kraken Pro domain or installed app, describe one exact integration job, and navigate independently to the official domain. Never copy an API secret, private key, QR payload, password, two-factor code, identity document, wallet private key, or seed phrase into notes, screenshots, tickets, source code, or chat.

Apply least privilege before generating the credential. Public Kraken documentation can explain available permissions, IP restrictions, expiration and API-key 2FA, but it cannot resolve regional interface differences for a particular integration or account. A read-only tax or portfolio tool should not receive trading or withdrawal authority; a trading tool normally should not receive withdrawal authority. If the vendor cannot state the exact endpoints and permissions it needs, stop before creating the key.

For official entry, retain only non-secret evidence: key label, purpose, enabled permissions, allowed IP range, expiry date, owner, review date and revocation test. Navigate independently to the official domain, then validate the smallest harmless call and confirm denied operations remain denied. If regional interface differences remains unresolved, revoke the key and redesign the scope.

2. API-key safety step: Purpose

The purpose step concerns one named integration job. Begin only from the official Kraken Pro domain or installed app, describe one exact integration job, and write a non-secret purpose statement.

Public Kraken documentation can explain available permissions, IP restrictions, expiration and API-key 2FA, but it cannot resolve future scope creep for a particular integration or account.

For purpose, retain only non-secret evidence: key label, purpose, enabled permissions, allowed IP range, expiry date, owner, review date and revocation test. Write a non-secret purpose statement, then validate the smallest harmless call and confirm denied operations remain denied. If future scope creep remains unresolved, revoke the key and redesign the scope.

3. API-key safety step: Read permissions

The read permissions step concerns balances, orders, trades or ledger data. Begin only from the official Kraken Pro domain or installed app, describe one exact integration job, and enable only required queries.

Public Kraken documentation can explain available permissions, IP restrictions, expiration and API-key 2FA, but it cannot resolve vendor endpoint needs for a particular integration or account.

For read permissions, retain only non-secret evidence: key label, purpose, enabled permissions, allowed IP range, expiry date, owner, review date and revocation test. Enable only required queries, then validate the smallest harmless call and confirm denied operations remain denied. If vendor endpoint needs remains unresolved, revoke the key and redesign the scope.

4. API-key safety step: Trade permissions

The trade permissions step concerns modify and cancel orders. Begin only from the official Kraken Pro domain or installed app, describe one exact integration job, and separate trading from reporting.

Public Kraken documentation can explain available permissions, IP restrictions, expiration and API-key 2FA, but it cannot resolve strategy behavior for a particular integration or account.

For trade permissions, retain only non-secret evidence: key label, purpose, enabled permissions, allowed IP range, expiry date, owner, review date and revocation test. Separate trading from reporting, then validate the smallest harmless call and confirm denied operations remain denied. If strategy behavior remains unresolved, revoke the key and redesign the scope.

5. API-key safety step: Funding permissions

The funding permissions step concerns deposit and withdrawal capabilities. Begin only from the official Kraken Pro domain or installed app, describe one exact integration job, and leave withdrawal disabled unless indispensable.

Public Kraken documentation can explain available permissions, IP restrictions, expiration and API-key 2FA, but it cannot resolve approval governance for a particular integration or account.

For funding permissions, retain only non-secret evidence: key label, purpose, enabled permissions, allowed IP range, expiry date, owner, review date and revocation test. Leave withdrawal disabled unless indispensable, then validate the smallest harmless call and confirm denied operations remain denied. If approval governance remains unresolved, revoke the key and redesign the scope.

6. API-key safety step: WebSocket access

The websocket access step concerns private-stream authentication. Begin only from the official Kraken Pro domain or installed app, describe one exact integration job, and enable only when used.

Public Kraken documentation can explain available permissions, IP restrictions, expiration and API-key 2FA, but it cannot resolve client compatibility for a particular integration or account.

For websocket access, retain only non-secret evidence: key label, purpose, enabled permissions, allowed IP range, expiry date, owner, review date and revocation test. Enable only when used, then validate the smallest harmless call and confirm denied operations remain denied. If client compatibility remains unresolved, revoke the key and redesign the scope.

7. API-key safety step: IP restriction

The ip restriction step concerns allowed client addresses. Begin only from the official Kraken Pro domain or installed app, describe one exact integration job, and whitelist stable trusted egress.

Public Kraken documentation can explain available permissions, IP restrictions, expiration and API-key 2FA, but it cannot resolve future IP changes for a particular integration or account.

For ip restriction, retain only non-secret evidence: key label, purpose, enabled permissions, allowed IP range, expiry date, owner, review date and revocation test. Whitelist stable trusted egress, then validate the smallest harmless call and confirm denied operations remain denied. If future IP changes remains unresolved, revoke the key and redesign the scope.

8. API-key safety step: Expiration

The expiration step concerns automatic credential lifetime. Begin only from the official Kraken Pro domain or installed app, describe one exact integration job, and set the shortest workable date.

Public Kraken documentation can explain available permissions, IP restrictions, expiration and API-key 2FA, but it cannot resolve renewal ownership for a particular integration or account.

For expiration, retain only non-secret evidence: key label, purpose, enabled permissions, allowed IP range, expiry date, owner, review date and revocation test. Set the shortest workable date, then validate the smallest harmless call and confirm denied operations remain denied. If renewal ownership remains unresolved, revoke the key and redesign the scope.

9. API-key safety step: Secret storage

The secret storage step concerns one-time key and QR handling. Begin only from the official Kraken Pro domain or installed app, describe one exact integration job, and store only in encrypted secret storage.

Public Kraken documentation can explain available permissions, IP restrictions, expiration and API-key 2FA, but it cannot resolve third-party retention for a particular integration or account.

For secret storage, retain only non-secret evidence: key label, purpose, enabled permissions, allowed IP range, expiry date, owner, review date and revocation test. Store only in encrypted secret storage, then validate the smallest harmless call and confirm denied operations remain denied. If third-party retention remains unresolved, revoke the key and redesign the scope.

10. API-key safety step: Review and revoke

The review and revoke step concerns ongoing ownership and removal. Begin only from the official Kraken Pro domain or installed app, describe one exact integration job, and test revocation and schedule review.

Public Kraken documentation can explain available permissions, IP restrictions, expiration and API-key 2FA, but it cannot resolve undetected copies for a particular integration or account.

For review and revoke, retain only non-secret evidence: key label, purpose, enabled permissions, allowed IP range, expiry date, owner, review date and revocation test. Test revocation and schedule review, then validate the smallest harmless call and confirm denied operations remain denied. If undetected copies remains unresolved, revoke the key and redesign the scope.

Decision scenarios

Scenario 1: when official entry becomes decisive

Consider a reader whose main constraint is Kraken Pro Settings and API page. The correct response is not to infer a universal platform or product winner. It is to navigate independently to the official domain, retain the evidence, and define a stop condition before funds or permissions are committed. If the evidence changes, the decision must be reopened. This produces a repeatable operating rule rather than a one-time opinion.

Scenario 2: when purpose becomes decisive

Consider a reader whose main constraint is one named integration job. It is to write a non-secret purpose statement, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 3: when read permissions becomes decisive

Consider a reader whose main constraint is balances, orders, trades or ledger data. It is to enable only required queries, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 4: when trade permissions becomes decisive

Consider a reader whose main constraint is modify and cancel orders. It is to separate trading from reporting, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 5: when funding permissions becomes decisive

Consider a reader whose main constraint is deposit and withdrawal capabilities. It is to leave withdrawal disabled unless indispensable, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 6: when websocket access becomes decisive

Consider a reader whose main constraint is private-stream authentication. It is to enable only when used, retain the evidence, and define a stop condition before funds or permissions are committed.