Key points
- Give an API key only the permissions it needs.
- Avoid withdrawal permission unless the workflow truly requires it.
- Use IP restrictions and separate keys where supported.
- Rotate and revoke keys when a service is no longer used.
Treat an API key as delegated authority
An API key can allow a third-party tool to read balances, place trades or perform other actions. The exact permission set matters more than the label 'API integration'. Review the requested scope before creating the key.
A portfolio tracker usually does not need the same authority as an execution bot. Separate keys can limit the impact of a single service compromise.
Reduce the blast radius
Use read-only access when possible. If trading permission is needed, avoid withdrawal capability unless the use case truly requires it. IP restrictions, subaccounts and dedicated keys can further isolate access where the platform supports them.
Never paste secrets into support messages or public configuration files. Store them using a secret manager or the protected credential system provided by the application.
Plan for revocation
Keep an inventory of active keys and the services that use them. Remove keys for tools you stop using and rotate credentials after suspected exposure.
A comparison of trading tools should disclose the permissions each integration requires and should not imply that an API connection is risk-free.
Primary reading
These official sources provide background for the risk and custody concepts used in this guide. Product-specific facts should still be checked against the relevant operator and jurisdiction.