A subscriber's API key expires, an allowed IP changes, or there is suspicion of a leak. It may seem enough to insert a new key and continue copying. But access to the exchange and the state of the trading account are different things. Changing credentials does not prove that an open position is closed, a protective order is preserved, or that a missed trader action will be restored.
The service owner with their audience needs a short protocol: who changes the key, who is responsible for positions during the break, and by what criteria the connection is again considered operational. Below is such a plan, not a promise of seamless replacement in any configuration.
Scheduled replacement and suspicion of leakage are different cases
During scheduled maintenance, it is possible to agree on the time in advance and check the account status. In the case of suspected compromise, the priority is different: the account owner revokes the suspicious key through the exchange's means and checks account security. Possible attacker access cannot be left for continuous copying.
Disabled withdrawal rights do not make a trading key harmless: permission to trade allows changing market exposure. Therefore, the new secret is not forwarded to the administrator via messenger, not put into a ticket, and not shown in a screenshot. The participant enters it independently into protected fields intended for this purpose.
If the key may have leaked, the usual plan below is supplemented by an exchange security procedure. Resuming the connection while it is unknown who else has account access is not recommended.
Before replacement, determine exactly what is connected
Record the exchange, the needed account or subaccount, the market, and the project user. The new key must correspond to the same intended account: a similar connection name does not confirm this. Separately find out if the old key is used by another robot or service. Revocation may interrupt not only copying.
The project owner and subscriber must have a shared answer to three questions:
- What trading actions can happen during work?
- Who monitors existing positions and orders?
- What if the new connection check fails?
Do not promise a mode of "new entries stopped, exits continue" until confirmed for a specific project. Stopping copying and closing a position are discussed separately: they are not a single operation.
Preserve the original state without secrets
Before scheduled replacement, the participant checks positions, active orders, and available balance directly on the exchange. A working note includes sufficient time in UTC, instrument, direction and volume of the position, identifiers of significant orders, and the person responsible for monitoring.
| What to record |
Why it is needed |
| Account, market and project user |
To avoid restoring access to a different connection |
| Positions and active orders |
To notice changes during the break |
| Last known copying event |
To mark the boundary of the checked interval |
| Responsible person and contact method |
So the issue does not remain between support and subscriber |
This is a maintenance log, not storage for API credentials. If the exchange documentation does not confirm the fate of orders after key revocation, do not assume: check their status separately.
Check permissions, then trading status
Create a new key according to the current instructions of your exchange. Permissions should correspond to the needed market; withdrawal rights are not required for CopyTrader. If IP restrictions are used, ask the service for current connection addresses rather than taking them from old correspondence.
The CopyTrader connection instructions describe checking keys in user settings. This helps detect access errors but does not confirm that the entire downtime period was properly handled. The exact procedure for saving new credentials and re-enabling must be clarified for your own configuration before changes.
After access verification, compare current positions and orders on the exchange with the original record. Is there any unknown execution? Is there any order capable of changing the position? Were there trader actions during disconnection? Do not start synchronization as a harmless test: it may lead to trading operations.
Example: key replaced, but work is not finished yet
The subscriber had an open position and a protective order. During replacement, the trader reduced their volume. The new key passes verification; however, the subscriber still has the previous position. This is not a reason to manually repeat the action immediately: first determine what orders were already sent and what was actually executed.
The operator records the break boundaries and passes to analysis the time, instrument, and operation identifiers without secrets. Order and position reconciliation helps clarify execution facts; it is not replaced by an API green status.
When to close a maintenance ticket
The work is complete when the required account and permissions are checked, remaining positions and orders are known, further management procedures agreed upon, and the old key revoked according to the accepted plan. The last is confirmed on the exchange, not just by removing credentials from the service.
It is convenient for the audience to prepare a memo in advance: where to enter the new key, what not to send to support, and what information to include in case of error. CopyTrader provides infrastructure for your service, not ready-made subscribers: a clear maintenance procedure remains part of the project owner's work. Such a procedure does not eliminate market risk but helps avoid confusing restored access with restored account control.
CopyTrader · Telegram