The two admin edit forms, and what they bypass

Beside the named actions on the admin console — approve, reject, suspend, activate, recalculate, delete for leaders; pause, resume, force stop for subscriptions — both entities also carry an ordinary edit endpoint that writes columns directly. Those two PUTs run none of the checks their named counterparts run, and none of the checks the customer-facing routes run on the very same fields.

They are worth knowing about for two opposite reasons. They are the only way to correct a mis-set risk parameter without asking the customer to do it. And they are the only way an administrator can put a leader or a subscription into a state the product's own rules forbid.

Where the edit forms actually are

Neither /admin/copy-trading/leader nor /admin/copy-trading/follower exposes them. Both of those tables are mounted read-only — canEdit, canCreate and canDelete are all off — so the row menu offers View plus the status actions and no Edit item at all. The edit form definitions exist in those pages' column files, but nothing renders them.

The one screen that does open them is Admin → CRM → Users → the user → the Copy Trading tab (/admin/crm/user/{id}). The leader table embedded there is mounted with edit and delete enabled. The subscription table below it has edit enabled and delete switched off — which matches the API, where a leader has a DELETE route and a subscription has none.

The Edit row action is not a dialog. It replaces the table with an inline edit form built from the table's columns, in place, inside the same CRM card — toolbar, rows and pagination all disappear until you save or cancel and it returns you to the list.

Everything else in this page is reachable only by calling the endpoint directly.

Editing a subscription

Gated on edit.copy_trading and counted against the 50 actions per hour limit. That limiter sits on the mutating admin copy-trading routes only — the two PUTs, the named leader and subscription actions, the leader delete, the bulk status change and the transaction reversal. Reading costs nothing: the lists, the two detail GETs, analytics, audit and health carry no limiter and are not counted against it. Every field is optional; only the fields present in the body are considered.

maxTradeAmount and riskMultiplier are accepted by the request schema and then silently dropped, because copy_trading_followers has neither column. The copy engine reads riskMultiplier when it sizes a copy and falls back to 1 when it is absent — which is every subscription, on every install. Treat it as a knob that does not exist rather than one set to a default.

The two risk caps that matter cannot be edited here

maxDailyLoss and maxPositionSize are returned by this endpoint's response and are shown on the subscription detail screen, but they are not in its allow-list. There is no admin route that writes them.

That is unfortunate, because they are the two per-subscription settings with real teeth:

Only the follower can change them, from their own subscription settings. If one is set wrongly, the fix is a conversation with the customer, not a console action.

Changing status here is a column write, not a teardown

The same warning applies in reverse. Writing ACTIVE over a STOPPED or PAUSED subscription revives it with no checks at all — the dedicated resume action refuses unless the subscription is currently PAUSED and its leader is ACTIVE, and this endpoint asks neither question. A subscription revived behind a suspended leader will not copy anything, but it does start counting again toward both the leader's follower count and the follower's copyTradingMaxLeadersPerFollower allowance.

This endpoint reports a failure even when it succeeds

The write and the audit entry are not in one transaction, and the audit entry hands a raw object to a text column. Sequelize refuses that, so the request ends in an error naming newValue — after the subscription row has already been changed.

What you see is an error toast. What happened is:

• the columns were written, and stayed written;
• no audit row was recorded, for any edit made this way.

Re-submitting to "make it stick" writes the same values again and fails again. If you use this endpoint, verify the result by re-reading the subscription rather than by trusting the response, and record the change somewhere yourself.

Editing a leader

Same permission, same 50-per-hour limit. Eight fields, taken straight from the body onto the row:

The route itself validates nothing. What survives is whatever the column definitions happen to refuse, and the messages you get back are database messages, not product ones.

Two more checks this endpoint skips:

• The customer's route refuses a profile edit unless the leader is ACTIVE. This one will happily rewrite a PENDING, REJECTED or SUSPENDED leader's profile.
• The customer's route refuses to set maxFollowers below the leader's current active follower count. This one allows it. Existing subscriptions are not touched — the number simply stops new followers until the count falls back under it.

Raising maxFollowers past the platform cap does nothing

Eligibility takes the lower of the leader's maxFollowers and the platform-wide copyTradingMaxFollowersPerLeader setting. Setting a leader to 5,000 while the platform cap sits at its default 1,000 leaves the effective ceiling at 1,000. To genuinely widen one leader's book you have to raise the platform setting as well — and that raises it for every leader.

status is not in this endpoint's allow-list. Approving, rejecting, suspending and reactivating are the dedicated actions, and only those actions carry the side effects — a suspension pausing every follower, for instance. A status value sent here is discarded.

What the subscription detail screen shows

/admin/copy-trading/follower/{id} is read-only for settings. It carries Resume, Pause and Stop, each behind a confirmation, and no edit form. Only the two destructive ones ask for a reason: Pause and Stop show a reason box and refuse to submit while it is empty. Resume shows the title, the description and the confirm button, nothing more — so a resume made from this screen carries no reason with it.

Its Copy settings card renders the copy mode plus only the sizing parameter that mode actually uses — a FIXED_RATIO subscription shows its ratio and not its fixed amount, and vice versa. A stale value left behind by an earlier mode is deliberately not displayed, because showing both implied both were in play. PROPORTIONAL shows neither and says the copy is scaled to the allocation.

The risk block underneath always renders all four of maxDailyLoss, maxPositionSize, stopLossPercent and takeProfitPercent, printing Not set where there is no limit. "No limit configured" is the single most useful thing a risk panel can tell you, so it is stated rather than left blank.

Below that, the Allocations card is where the subscription's money physically is: used against allocated, per market, base and quote, with inactive allocations marked. Read it before you stop anything.

What each edit leaves in the audit trail

Three things follow from that table.

A subscription edit leaves no trail at all — the audit write is what fails, so there is nothing to find afterwards.

A leader edit is indistinguishable from the leader editing their own profile. Both write LEADER / UPDATE with the same before-and-after values. The only discriminator is which actor column is populated: an administrator's edit fills adminId, the leader's own edit fills userId. The audit endpoint accepts an adminId filter and an entityId filter, which is how you separate them.

The IP address on these rows is not real. The four subscription routes that set one read it from a property the request object does not have, so every row they write records the literal string unknown. Do not treat it as evidence.

Which one to reach for

Endpoint shapes, permissions and rate limits for the whole surface are in the API reference.