API keys behave like machine credentials, so they need an owner, purpose, expiration plan, and incident path. A key created for a portfolio report should not slowly accumulate trading and withdrawal rights because a script failed. This guide describes a lifecycle that works across exchanges with different names for permissions. Always compare the current provider documentation with the controls in the account.
Create an inventory before keys
List every application, owner, environment, source IP, endpoint family, key id, creation date, last use, and permission set. Include keys in spreadsheets, bots, tax tools, and old laptops. A key without an owner is an incident waiting for a trigger. Keep the secret out of the inventory; store only an identifier or fingerprint.
Request the smallest scope
Map each application function to an API endpoint and permission. A reporting job may need balances and fills but not order placement. A trading bot may need orders but not withdrawals. Disable transfer and universal permissions. Use an IP allowlist and expiration if available. Document the business reason and reviewer so a later change can be challenged.
Test in a non-destructive mode
Use a sandbox or read-only endpoint to confirm authentication, pagination, decimal handling, and rate limits. The test should not place an order or request a withdrawal. Log request category and response status while masking keys and account identifiers. If the tool fails, fix the client or scope deliberately; do not enable every permission “temporarily.”
Review usage against intent
Compare access logs with the inventory and expected schedule. Alert on new endpoints, source IPs, bursts outside the polling window, and requests for transfer or withdrawal methods. A successful API response does not make an unexpected action acceptable. Rotate keys when an employee leaves, a host changes, or a vendor cannot explain a request.
Rotate without downtime
Create a replacement key with the same or narrower scope, deploy it through a protected secret store, test a read-only call, then revoke the old key. Keep a change record with both identifiers and the precise cut-over time. Do not copy secrets into issue trackers or paste them into a terminal command that will remain in shell history.
Respond to compromise
Revoke the affected key, disable account trading or withdrawals through the official security center when appropriate, and review sessions and recent activity from a clean device. Preserve logs and support tickets. A read-only leak can still expose private portfolio data, while a trading or withdrawal leak may require urgent containment. Never send the key itself to support as proof.
Retire and audit
Delete unused keys, close the associated integration, and record the retirement reason. Review the inventory quarterly or after a platform migration. A lifecycle report should show creation, scope changes, rotations, and revocation evidence. That record demonstrates control without claiming that any exchange or vendor is risk-free.
Worked example: safe rotation
A reporting vendor changes its server IP. Create a replacement read-only key with the new allowlist, deploy it through the secret store, run one balance request, and then revoke the old key. Compare logs before and after the cut-over and record the exact time. If the new key requests an order endpoint, stop the deployment and correct the scope. A lifecycle record should show owner, purpose, permissions, IP, creation, rotation, and revocation without storing the secret itself.
Operational handoff
For a vendor integration, include a termination clause and a contact who can revoke access when the contract ends. Test that a disabled key returns the documented authorization response and that the application fails closed rather than creating a new key automatically. Keep a small synthetic account or sandbox for these tests. Production logs should contain enough metadata to investigate an incident but never full signed requests, API secrets, or private account payloads.
Frequently asked question
Should a key be shared by several automation jobs?
Prefer one key per purpose and environment. Separate keys make revocation and attribution possible; a shared key turns one script compromise into a multi-system incident.