What is not available
Payouts, trader logins, commission, KYC — the boundaries of this platform, and what to do instead.
Things a prop firm might reasonably look for here and will not find. None of these are oversights or roadmap items we are being coy about — each one is a deliberate boundary, and knowing where it sits will save you building against something that is not coming.
Payouts and trader payments
There is no endpoint to charge a trader for a challenge, and none to pay a trader their split. No /payouts, no /challenge-purchases, no split-payment plumbing.
- Why: money moving between your firm and your traders is your relationship, your licensing position and your liability. Putting it through us would make us a party to it.
- What to do instead: run it in your own stack. Use
account_types.price_centsto record what you charge so your dashboard can display it, and analytics to compute what a passing trader is owed. The numbers are all here; the transaction is yours.
This existed once, as a trader storefront with self-service checkout, and was removed when the scope narrowed. It is not returning without a deliberate decision.
Trader logins, KYC and documents
No trader authentication, no password reset, no trader dashboard, no document upload, no KYC status field.
A trader here is a record — a name and an email — and the only thing that logs into the executor is a set of account credentials, which name an account rather than a person. Whoever holds the password trades that account; we never model them as a user. Identity, onboarding and compliance live in your systems.
Commission, swap and financing
The simulator charges none of them, so profit_total.loss_commission and profit_total.profit_swap are always 0. If your challenge economics assume trading costs, they are not reflected in any number this API returns.
Worth planning around
This is the gap most likely to matter to you, because it makes a simulated account slightly more generous than a live one. If you need modelled costs, tell us — it is a change to how fills are priced, not a field we can add.
Also not modelled
| Not available | Why |
|---|---|
| Multi-currency accounts | Every account is USD. currency is reported as a constant rather than omitted. |
| Order source (EA vs manual vs signal) | Nothing records how an order arrived, so profit_type reports everything as manual. |
| Time-based rules | News blackouts and inactivity timeouts need a scheduler, which would put the breach decision behind a timer. The catalogue lists them as unavailable and the API refuses them. |
| Changing a live account's rules | Versions are frozen at creation. See why. |
| Refunding a credit | A breached or archived account does not return its credit. That is what you paid for when it was created. |
| Real order routing | Fills are simulated against live prices. Nothing reaches a broker, an exchange or any venue, ever. |
| Affiliate and discount codes | Part of selling challenges, which happens in your stack. |
If one of these is a blocker
Some of the above are boundaries we will not cross; others are simply not built. The difference matters to you, so ask rather than guess — book a call and we will tell you plainly which is which.