Sandbox Keys and Paper Accounts: Testing Your MyFundedPerps Integration Safely

Every automated strategy should prove itself on paper before it touches a live challenge account. The MyFundedPerps API sandbox exists for exactly that: a full test environment that runs the same engine, endpoints, order types, rate limits, and trading rules as the live API, against real market data, without any risk of a test order reaching a real account. This article covers how sandbox access works, how to set up test keys, what differs from live, and how to graduate an integration to a real challenge account.

If you are new to the platform's developer tooling overall, start with our API quickstart article, then come back here before you connect anything to a purchased challenge.

What the MyFundedPerps API sandbox actually is

The sandbox is a separate hostname serving the complete REST API surface:

https://sandbox.myfundedperpetuals.com

The same code powers both environments, so the behavior you observe in testing is the behavior you get in production: identical endpoints, identical order types (including TWAP, VWAP, and scaled orders), identical rate limits, and identical trading-rule enforcement. The only difference is which accounts are reachable. Sandbox keys can only see sandbox accounts, and live keys can only see live accounts. The isolation is enforced in both directions, so a known order ID or client order ID from one environment grants nothing in the other.

Who gets access, and for how long

Sandbox access is included with a challenge purchase and stays active for 90 days after each purchase. Buying another challenge extends the window. Access is checked continuously: when the window lapses, sandbox requests return 403 with the error code sandbox_access_expired until a new purchase refreshes it.

That design means the sandbox is not a permanent free playground. It is a development tool tied to being an active customer, which is reasonable: the environment serves real market data and full engine capacity.

Setting up test keys and paper accounts

Setup takes a couple of minutes:

1. Open API Key settings at myfundedperpetuals.com/settings?section=api-keys.
2. Select Create API Key and choose the Test (Sandbox) environment.
3. Use the generated key, which begins with the prefix fp_test_.

Test keys automatically cover every sandbox account you own. If you have no active sandbox account when you create a test key, one is created for you. Sandbox accounts start with a $100,000 simulated balance and follow the same trading rules as evaluation accounts, which means they can breach. A breached sandbox account is replaced automatically the next time you create a test key, and you can hold up to ten sandbox accounts in total.

A quick smoke test once you have a key:

curl https://sandbox.myfundedperpetuals.com/v1/accounts \
  -H "Authorization: Bearer fp_test_..."

The response lists only your sandbox accounts. Every endpoint in the API reference at docs.myfundedperpetuals.com behaves the same way on both hosts, so your integration code needs no special casing beyond the base URL and the key.

Differences from the live environment

The isolation rules are strict and worth internalizing before you design your state handling:

A few details deserve emphasis:

• Using a key on the wrong host returns 401 with a message naming the correct host. Handle that message; it is the fastest way to catch a misconfigured environment variable.
• Sandbox accounts never appear in live API responses, and challenge accounts never appear in sandbox responses. This applies to position, order, TWAP/VWAP, and scaled-order IDs, client order IDs, modifications, cancellations, and idempotent retries. Inaccessible individual resources return 404, and a client order ID lookup returns an empty list.
• Archived accounts and their orders, positions, and strategy history are unavailable through trading endpoints in either environment, including previously successful trading-request replays.
• In the web app, sandbox accounts carry a Sandbox badge in the account switcher, and their dashboard never shows funded-stage progression because a sandbox account cannot become funded.

Why breach testing is a feature

Because sandbox accounts enforce real evaluation rules, they can fail. That is useful. Your integration should know how to handle:

• 422 rejections from trading rules, including daily loss and max loss enforcement.
• 429 rate-limit responses with Retry-After.
• 403 sandbox_access_expired when your window lapses.
• Trader Lockout responses (422 with account_trader_lockout_active) if you test that setting.

Run your failure paths deliberately in the sandbox: oversize an order, exceed a rate budget, let an account breach, and confirm your code logs and reacts the way you expect. Catching a mishandled rejection on paper is free; catching it on a funded account can cost you the account. For the deeper mechanics of safe retries, read our article on idempotency and rate limits.

Going live

When your integration behaves correctly in the sandbox, the migration is deliberately boring:

1. Create a live key with the same access level in API Key settings.
2. Point your client at https://developers.myfundedperpetuals.com.
3. Select the challenge accounts the key should reach.

No other code changes are needed. Keep the sandbox key active for regression testing whenever you change your strategy logic; every new purchase refreshes the 90-day window, so active customers effectively keep the environment indefinitely.

Before you trade a real account, also make sure you understand the rules your code must respect. Our myfundedperps-rules-explained article covers the evaluation and funded rule sets, myfundedperps-account-limits explains the $300K total and $100K per model allocation caps, and myfundedperps-static-drawdown covers the loss floor your bot will be trading against.

Frequently asked questions

Is the MyFundedPerps API sandbox free to use?

It is included with a challenge purchase and remains active for 90 days after each purchase. There is no separate charge, but it is not a standalone free product; when the 90-day window lapses, sandbox requests return 403 sandbox_access_expired until a new purchase refreshes access.

Can a sandbox order accidentally reach my real challenge account?

No. Test keys authenticate only on the sandbox host and can only reach sandbox accounts. Live keys authenticate only on the live host and cannot see sandbox accounts. Order IDs, client order IDs, and idempotent retries are all scoped to their environment.

How many sandbox accounts can I have?

Up to ten at a time. Each starts with a $100,000 simulated balance and enforces the same rules as an evaluation account. A breached account is replaced automatically the next time you create a test key.

Do sandbox accounts show up on leaderboards or in analytics?

No. Sandbox accounts are excluded from analytics, leaderboards, certificates, and payouts. They exist only for integration testing, and they carry a Sandbox badge in the web app's account switcher.

What changes when I move from sandbox to live?

Only the hostname, the key, and the account selection. Create a live key with the same access level, point your client at developers.myfundedperpetuals.com, and choose the challenge accounts the key should reach. The endpoints and behavior are identical.