The Account Trading Policy Endpoint: Pre-Flight Checks Before Every API Order

A well-built trading bot does not discover account restrictions by eating 422 rejections. The MyFundedPerps trading policy API gives you a single endpoint that reports the effective rules, locks, restrictions, and platform limits on an account before you submit anything: GET /v1/accounts/{account_id}/trading-policy. This article walks the response field by field, explains how exposure caps interact with it, and covers the right refresh cadence so you stay informed without burning your read budget.

Calling the MyFundedPerps trading policy API

Call the endpoint with a read or trade credential:

GET /v1/accounts/{account_id}/trading-policy

Only owned, non-archived accounts inside the credential's live or sandbox environment and account allowlist are visible. Any other account ID returns 404, which doubles as a scope check: if you expected access and got a 404, your key's allowlist or environment is wrong.

The response's data object is a timestamped, advisory snapshot. That word, advisory, is the single most important thing to understand about this endpoint, and we will come back to it.

What the snapshot contains

The policy response covers five categories of information:

The limits object uses snake_case keys such as max_open_positions, max_position_value_usd, max_resting_orders, min_order_notional_usd, order_cooldown_ms, and trades_per_minute. Read these at runtime instead of hardcoding values you observed once.

Use account_rules, not copied plan numbers

One line in the docs saves integrations from a whole class of bugs: current plan rules replace retired account snapshots for daily loss, drawdown, consistency, and profit target, and minimum-trading-day account overrides are retired. Use the returned values instead of copying plan numbers into your integration. A zero percentage disables that rule.

The two inactivity windows are different by design: evaluation-inactivity (30 days) and funded-inactivity (7 days) are universal product rules pinned in code. They are reported for every account except rule-less competition products, and no plan or account override can change them. If your bot trades infrequently, these are the numbers that decide whether the account survives; see our account inactivity rules article for the full picture.

Market exposure caps in the policy context

The endpoint also frames how market exposure caps are enforced. A market's cap limits combined open notional (long plus short) across accounts of the same challenge model and account size. The server includes existing exposure and rejects a fill that would exceed the configured cap; closing or reducing positions is never blocked.

Two operational details:

• Competition accounts use a separate per-user allowance from other accounts. Matching competition accounts share their own cap per market, product, and size, and competition orders remain subject to exposure rejection.
• An existing position keeps its enrolled exposure group through additions, reductions, and reversals, even if challenge offerings change. A new position after fully closing uses the current product grouping.

Cap enforcement defaults to enabled for newly added markets, but a numerical cap must still be configured. Check the current caps at myfundedperpetuals.com/exposure-caps; our myfundedperps-exposure-caps article explains the mechanics, and myfundedperps-markets-guide lists launch markets. Any specific leverage or cap figure you see published is as of September 2026 and may have changed since; the live page is authoritative.

Advisory means advisory: what preflight cannot do

This is the section most integration bugs come from. The policy snapshot:

• Does not reserve margin, position slots, order slots, trade-window allowances, or market liquidity.
• Does not evaluate a proposed order or fetch fresh prices.
• Is not a guarantee: a false opening_exposure_restricted does not mean your order will pass.

Placement and settlement remain authoritative for current balances, rate-window usage, cooldown, market hours, competition markets, and all other order-dependent rules. Evaluation rules can also depend on stage and fresh equity. The correct mental model is: preflight tells you what is knowable now, and the engine decides at execution.

For market-specific constraints, check market metadata and request a quote rather than inferring them from policy. The saved slippage-protection maximum is enforced server-side and included in the policy; other saved interface preferences, like display defaults, are not order policy.

Copy trading fields for API clients

If you run copy groups, three fields matter. copy_follower_locked tells you a follower rejects manual entries, reductions, closes, and protective-order changes while its group is enabled. copy_stop exposes stopped_at, completed_at, acknowledged_at, and reason, and it remains available after the group is deleted, so a reconnecting client can still explain why copying stopped. copy_scope_blocked means an enabled group led by the selected account contains a member your credential cannot access: fix it with a credential authorized for every member in the same environment, or change the group on the website. A false value does not cover stale working copied orders; those are checked again at execution. Our copy trading article covers the group model itself.

Refresh cadence: informed without polling

Fetch policy when you select an account, and refresh after a relevant rejection or a configuration change. Do not poll once per second: every call consumes the shared REST read budget (120 reads per minute per key, 300 per user across keys, as documented in errors-and-rate-limits and our idempotency and rate limits article). Event-driven refresh, triggered by a 422 or a config change you made, keeps you current at a fraction of the cost. Test the whole flow in the sandbox before live; the same endpoint and rules apply there.

Frequently asked questions

What does the MyFundedPerps trading policy API return?

A timestamped advisory snapshot of the account's effective rules, restrictions, locks, copy-trading state, platform limits, slippage tolerance bounds, total notional ceiling, and fee-exemption status. Call GET /v1/accounts/{account_id}/trading-policy with a read or trade credential.

If opening_exposure_restricted is false, will my order succeed?

Not necessarily. The snapshot is advisory: it does not reserve margin, slots, or liquidity, and it does not evaluate your specific order. Placement and settlement remain authoritative for balances, cooldowns, market hours, and all order-dependent rules.

Can I hardcode my plan's daily loss and drawdown numbers?

No. Current plan rules replace retired account snapshots, and account-level overrides are retired. Use the values returned in account_rules at runtime; a zero percentage disables that rule.

How often should I poll the trading policy endpoint?

Do not poll on a timer at all. Fetch when selecting an account and refresh after a relevant rejection or configuration change. Polling consumes the shared REST read budget and gains you nothing between events.

Why do I get a 404 for an account I own?

The endpoint only sees owned, non-archived accounts inside the credential's live or sandbox environment and account allowlist. A 404 means the account is archived, in the wrong environment, or outside the key's selected accounts.