Update a trading rule
Update an existing trading rule. Admin only.
Only provide fields you want to change. Use null to clear optional numeric fields.
Example - Update limits:
curl -X PATCH "https://api.example.com/platform/v1/organization/trading-rules/{ruleId}" \
-H "X-API-Key: hp_live_your_key_here" \
-H "Content-Type: application/json" \
-d '{"maxLoss": 6000, "dailyLoss": 3000}'
Example - Clear a field:
curl -X PATCH ".../{ruleId}" \
-d '{"consistency": null}'
Example - Set a contract scaling plan:
curl -X PATCH ".../{ruleId}" \
-d '{"scalingPlan": {"basis": "balance", "tiers": [{"profit": 0, "maxContracts": 1}, {"profit": 1000, "maxContracts": 2}, {"profit": 3000, "maxContracts": 5.5}]}}'
Example - Change the micro conversion ratio (5 micros = 1 mini):
curl -X PATCH ".../{ruleId}" \
-d '{"microConversionRatio": 5}'
Micro contract conversion (microConversionRatio):
maxContracts (and scaling-plan tiers) are denominated in mini-equivalent units. Micro contracts (MES, MNQ, MGC, …) are converted using the rule set’s microConversionRatio — how many micros count as 1 unit toward the limit:
| Ratio | maxContracts: 10 allows |
|---|---|
10 (default, CME notional ratio) | 10 minis or 100 micros, or any equivalent mix |
5 | 10 minis or 50 micros |
1 | 10 contracts total — micros count the same as minis |
E-mini and full-size contracts always count as 1 unit each; the ratio only affects micros. Omit the field (or PATCH it to null) to use the default 10:1 conversion. Different plans can use different ratios by pointing them at different rule sets. Enforcement is account-wide and real-time in the trade engine.
Example — a plan where 5 micros equal 1 mini:
{ "maxContracts": 10, "microConversionRatio": 5 }
Scaling plans (scalingPlan):
Position limits: pick the right field
maxContracts counts engine units and a rule is not tied to a market, so
one unit is one futures contract but 0.001 BTC on the Binance perpetual. The
same number therefore means different things depending on which account the rule
backs. Use maxPositionByMarket for anything that is not plain futures:
{
"name": "50K BTC Perp",
"maxLoss": 2000,
"dailyLoss": 1000,
"maxPositionByMarket": { "BINANCE": 0.5 }
}
That is half a Bitcoin — no conversion, no engine units. Rejections quote it back the same way:
Order would exceed the BINANCE position limit on this account: 0.600 BTC requested, limit 0.500 BTC.
| Field | Counts in | Scope | Use for |
|---|---|---|---|
maxPositionByMarket | the market’s own unit (BTC) | that market only | crypto, and any fractional contract |
maxContracts | mini-equivalents (micros via microConversionRatio) | all instruments | futures |
A market named in maxPositionByMarket is not also gated by
maxContracts — a market gets one limit or the other. Send null to clear
every per-market limit and put all markets back under maxContracts.
Instead of a flat maxContracts limit, you can define profit-based tiers that grow the trader’s position size as they make profit:
{
"scalingPlan": {
"basis": "balance",
"tiers": [
{ "profit": 0, "maxContracts": 1 },
{ "profit": 1000, "maxContracts": 2 },
{ "profit": 3000, "maxContracts": 5.5 }
]
}
}
profitis in dollars relative to the account’s starting balance. The first tier must be0— it defines the starting limit.- Alternatively, tiers can use absolute
balancethresholds instead ofprofit(all tiers must use the same key). The first tier defines the starting limit — set its threshold at (or below) the account size:
{
"tiers": [
{ "balance": 50000, "maxContracts": 1 },
{ "balance": 55000, "maxContracts": 2 },
{ "balance": 60000, "maxContracts": 5.5 }
]
}
Note: balance thresholds tie the rule to one account size — a 55000 tier means something very different on a 25K vs 100K account. Profit-based tiers are portable across account sizes; prefer them unless all accounts on this rule share one size.
maxContractsis in mini-equivalent units and supports 0.1 steps. Micros count as 1/microConversionRatioof a mini (default 10), so5.5allows 5 minis or 55 micros (e.g. 5 ES or 55 MES) at the default ratio.basiscontrols when tiers activate/deactivate:Value Behavior balanceMeasured against current balance — limits scale back down if the balance drops below a threshold (default) high_water_markMeasured against the best balance reached — tiers unlock permanently - When
scalingPlanis set it overridesmaxContracts. Remove it ("scalingPlan": nullon PATCH) to fall back to the flat limit. - Enforced in real time at order placement by the trade engine.
Consistency rule (consistency + related fields):
Caps how much of a trader’s profit may come from a single day. The daily cap is:
daily_cap = round(base × consistency%, 2)
+ starting_balance × consistencyTolerancePct%
+ consistencyLeniency
A day whose net PnL reaches or exceeds the cap fails the rule (the boundary is inclusive). The formula is selected automatically by account type:
- Evaluation accounts — the rule gates passing: base defaults to max(profitTarget, totalPnl), and the trader also needs at least
consistencyMinDaysprofitable days (default: ceil(100/consistency), so 50% → 2 days). Reaching the profit target with over-concentrated gains does NOT fail the account — it simply stays active until gains are spread out, and the account’scompletionPendingReasonexplains exactly why. - Sim-funded accounts — the rule gates payouts: base is the profit in the current payout cycle (since the last payout with
consistencyReset).
Enforcement is opt-in per rule set (consistencyEnforced, default false — the historical behavior where the consistency % was informational only). Existing accounts are unaffected until you enable it.
Example — MFFU-style template: { "consistency": 50, "consistencyEnforced": true, "consistencyTolerancePct": 0.2 } on evaluation rules, and { "consistency": 50, "consistencyEnforced": true, "consistencyLeniency": 40 } on Builder sim-funded rules.
Sim-funded accounts — limits are optional per rule set:
Every trading limit on a rule set applies to sim_funded accounts exactly like evaluations when set, and is disabled when 0/omitted — so you choose per template who enforces funded limits:
- Platform enforces (recommended): attach a rule set with real values, e.g.
{ "dailyLoss": 1500, "maxLoss": 2500, "maxContracts": 5, "consistency": 50, "consistencyEnforced": true, "consistencyLeniency": 40, "maxPayouts": 5, "payoutMllLockOffset": 100 }— we enforce limits live, gate payouts on consistency, and fire the webhooks. - You enforce: attach a permissive rule set (limits
0) and run your own logic; we still execute trades and payouts.
profitTarget never completes a sim-funded account — funded accounts withdraw, they don’t “pass” — so it is safe to reuse an eval-style rule set on funded accounts.
Warning: Changing rules affects how accounts using these rules are evaluated. Changes apply to future evaluations, not retroactively.
Error Codes:
| Code | Description |
|---|---|
RULE_NOT_FOUND | No rule exists with this ID |
RULE_NOT_IN_ORG | Rule belongs to a different organization |
RULE_NAME_EXISTS | Another rule already has this name |
NO_FIELDS_TO_UPDATE | No valid fields provided |
ADMIN_REQUIRED | Only admins can update rules |
Authorizations
JWT Bearer token for user session auth. Format: "Bearer {token}". Used by User and Organization endpoints.
Path Parameters
The rule ID to update
Body
New rule name (must be unique)
"Updated Rule Name"
New description (null to clear)
"Updated description"
New profit target
12000
New daily profit cap
New max profit cap
New daily loss limit
3000
New max loss limit
6000
New daily drawdown limit
New max drawdown limit
Change drawdown calculation method
static, trailing, eod Unit of maxDrawdown. "percent" (default) = % of the reference. "dollars" = a fixed dollar amount below the reference — required for zero-based (e.g. $0 sim funded) accounts, where any percent of $0 is a $0 floor. Example: drawdownType "trailing" + denomination "dollars" + maxDrawdown 1000 = a $1,000 trailing max loss whose floor starts at -$1,000.
percent, dollars "percent"
For trailing drawdowns: the floor stops climbing once it reaches initialBalance + this many dollars and locks there (the "ceiling"). Example: 100 on a $0 sim funded locks the floor at +$100 once equity has peaked $1,100. null/absent = the floor trails forever.
100
Display-only permission flag shown to traders: trading during news events (default true). Not engine-enforced.
true
Display-only permission flag shown to traders: microscalping (default true). Not engine-enforced.
true
Display-only permission flag shown to traders: holding positions over the weekend (default true). Not engine-enforced.
true
Display-only permission flag shown to traders: holding positions overnight (default true). Not engine-enforced.
true
New consistency requirement (% — see consistency notes)
Opt-in enforcement switch. false (default) = consistency % is informational only. true = the engine gates evaluation completion (evaluation accounts) or payout eligibility (sim_funded accounts) on the consistency rule.
true
What the consistency % applies to. null (default) = automatic by account type: evaluation → max_target_or_pnl (cap grows once total PnL exceeds the target), sim_funded → cycle_profit (profit since the last consistency reset). max_profit_target_or_pnl is accepted as an alias of max_target_or_pnl.
max_target_or_pnl, max_profit_target_or_pnl, total_pnl, profit_target, cycle_profit "max_target_or_pnl"
Daily-cap buffer as a percent of starting balance, added on top of base × consistency%. Example: 0.2 = $100 buffer on a $50,000 account.
x >= 00.2
Flat dollar buffer added to the daily cap (e.g. 40 = $40 leniency on funded payout consistency).
x >= 040
Minimum profitable days required to pass an evaluation. null (default) = automatic ceil(100 / consistency), e.g. 50% → 2 days, 40% → 3 days. 0 = disabled.
x >= 02
A trading day counts as profitable when its net PnL is at least this many dollars. Default 0 (any non-negative traded day counts).
x >= 00
When set, the Nth processed payout fires the account.max_payouts_reached webhook (e.g. "trader goes live after 5 payouts"). null = unlimited.
x >= 15
Default loss-floor offset used by payouts requesting move_mll_to_lock: floor = initial balance + offset. Can be overridden per payout with lockBalance.
x >= 0100
Per-market position limits in each market's own unit — {"BINANCE": 0.5} is half a Bitcoin, not 500 of anything. A market listed here is measured against this limit instead of maxContracts, so it is never gated twice; markets left out fall back to maxContracts in mini-equivalents. Prefer this over maxContracts for any market whose contract steps fractionally.
New max contracts limit (mini-equivalent units). A rule is not tied to a market, so this is always counted in ENGINE units: one unit is one futures contract, but 0.001 BTC on the Binance perpetual. A 0.1 BTC cap is therefore 100, and 1 BTC is 1000. Read quantityStep on the contract to convert.
How many micros count as 1 unit toward maxContracts (null resets to the default 10)
x >= 15
New scaling plan (replaces existing; null to remove and fall back to maxContracts)
Replaces the existing personal risk policy in full; null removes it and leaves traders unconstrained.
New metadata. Replaces existing metadata wholesale unless mergeMetadata is true.
When true, the provided metadata keys are merged into the existing metadata instead of replacing it entirely
true
Related topics
Update a trading planCreate or update a copy trading configCreate a new trading ruleGet trading rules for your organizationGet a specific trading rule