ProjectX vs TopstepX: Platform, API, and Permission Explained
ProjectX supplies gateway technology while TopstepX is Topstep's branded trading environment; this guide separates product identity, API access, and account-stage permission.
The plain-language distinction
ProjectX is the gateway technology provider; TopstepX is Topstep's branded platform and account experience powered by that technology.
The names appear together because TopstepX API access uses ProjectX infrastructure and documentation. They should not be treated as interchangeable legal or account concepts. ProjectX documents the technical API: authentication, account search, contracts, orders, positions, history, and real-time data hubs. Topstep controls who may link a TopstepX profile, which Topstep accounts are eligible, and what trading behavior is allowed at each account stage.
This distinction matters whenever a connector asks for a platform type. Selecting ProjectX usually describes the protocol family the software will speak. Selecting or linking TopstepX identifies the branded destination and account context. Neither label by itself grants permission to automate. Technical connection is not permission; private server order relay and Live Funded API limits must be verified in the current official rules before every deployment.
Policy-sensitive as of August 30, 2026
Topstep says order-flow automation may not run through a VPS, VPN, or remote server, and its Live Funded Account page says automated trading via the ProjectX API is prohibited in the LFA. Recheck both official pages because these restrictions can change.
Map each name to the decision it controls
Use ProjectX documentation for wire behavior and Topstep documentation for subscription, linking, account eligibility, and trading policy.
A developer troubleshooting an HTTP request should look to the ProjectX Gateway reference. For example, the documented order placement route is a POST to the TopstepX API order endpoint with accountId, contractId, type, side, and size. Optional price and bracket objects depend on order type. Rate-limit documentation currently separates historical bar retrieval from other authenticated endpoints and describes HTTP 429 behavior.
A trader deciding whether the request is allowed must read Topstep's current materials. Topstep's API-access instructions describe creating a ProjectX Dashboard account, purchasing API access, linking that subscription to the TopstepX profile, and generating a key inside TopstepX. The same help article imposes device and remote-server restrictions. The Live Funded parameters separately describe limits for the LFA stage. Code should not infer policy from a successful login.
| Question | Primary authority | What to verify |
|---|---|---|
| How is an order encoded? | ProjectX Gateway docs | Current endpoint, enum values, required fields, and response |
| How is a Topstep key created? | Topstep API-access help | Subscription, profile link, eligible account, and key handling |
| May this account stage use it? | Topstep rules | Trading Combine, Express Funded, and Live Funded restrictions |
| May it run on a server? | Topstep terms and API help | Personal-device requirement and order-relay prohibition |
What the official ProjectX order API actually expects
The official order route expects a resolved numeric account ID and a ProjectX contract ID, not a chart ticker and prop-firm nickname.
ProjectX documents integer order-type and side values. At the reviewed date, type 1 is Limit, 2 is Market, 4 is Stop, 5 is TrailingStop, 6 is JoinBid, and 7 is JoinAsk; side 0 is Bid and side 1 is Ask. An integration should use the current reference rather than freezing those values in an unreviewed spreadsheet. Limit, stop, and trail prices are optional only when they do not apply to the selected order type.
The strategy-facing payload should not expose those protocol details unless necessary. A normalization layer can accept buy, sell, market, limit, and a root symbol, then resolve an eligible account and exact contract. It should preserve the source event ID in a unique custom tag when appropriate and enforce uniqueness rules. The response's success field and orderId are broker acknowledgements, not evidence that the order filled.
{
"accountId": 465,
"contractId": "CON.F.US.DA6.M25",
"type": 2,
"side": 0,
"size": 1,
"customTag": "strategy-20260830-00041"
}Why subscription, linking, and key generation are separate
Topstep's documented setup requires the API subscription to be linked to the TopstepX profile before a usable API key can be generated.
The separate steps explain a frequent User lacks subscription error. Buying ProjectX API access does not automatically associate it with a TopstepX profile. The current Topstep flow starts in the ProjectX Dashboard, then requires a ProjectX Linking action from the TopstepX API settings, confirmation that the account appears in the ProjectX Dashboard, and finally key generation in TopstepX.
Treat the generated key like a password. Topstep warns that it grants trading access to every eligible account under the profile. Store it in a protected local secret store, never in Pine Script, a webhook body, browser source, public repository, or support screenshot. If a key is exposed, rotate it and update every authorized client. A connector should list accounts after authentication and require an explicit account allowlist rather than trading the first result.
- 1
Confirm the stage and rules
Identify the exact Topstep account stage and read the current API, device, and automation rules.
- 2
Establish API access
Complete the current ProjectX subscription and TopstepX profile-linking flow.
- 3
Generate and protect the key
Create the key in TopstepX and store it only on the permitted personal device.
- 4
Discover, then allowlist
List eligible accounts and contracts, then explicitly select the intended account IDs.
A successful API call does not settle policy
Authentication proves that credentials work; it does not prove that the deployment location, account stage, or strategy behavior is allowed.
Topstep's current API-access article permits custom bots subject to platform rules and its HFT prohibition, but it also says all trading activity must originate from the trader's personal device. The article prohibits VPS, VPN, and remote-server use for order flow, including placing, changing, cancelling, triggering, routing, or relaying orders. A private server may perform listed supporting work such as research, historical storage, logging, analytics, read-only dashboards, and receiving copies of the trader's own state.
The Live Funded Account page creates another boundary: automated strategies may be permitted generally, but automated trading through the ProjectX API is stated to be prohibited in the LFA. Do not generalize permission from a Practice, Trading Combine, or Express Funded test to Live Funded. Technical connection is not permission; private server order relay and Live Funded API limits must be verified in current official rules.
- Record the account stage alongside every deployment approval.
- Treat a promotion or migration as a mandatory policy-review event.
- Keep any order-triggering component on the location the current rules permit.
- Use server-side systems only for functions the current Topstep language expressly allows.
- Pause automation when policy, account stage, or eligibility cannot be established.
How to configure a connector without mixing the layers
Choose the ProjectX protocol adapter, bind it to the authorized TopstepX profile, and store policy approval as separate configuration.
A robust platform record should contain provider type, credential reference, discovered account ID, allowed contract roots, risk caps, and account stage. It should not use an email address as an order account ID or assume every account returned by the profile is eligible. Contract search and account discovery happen before the first signal is armed, and the resulting identifiers should be visible to the operator.
Keep policy controls outside the protocol adapter. The adapter answers whether it can authenticate, subscribe, and submit. A deployment gate answers whether it may do so for this firm, account stage, device, and strategy. This separation avoids a dangerous implementation pattern where successful technical discovery automatically enables trading. It also makes a later policy change enforceable without rewriting order code.
Do not hide the stage
Display Practice, Trading Combine, Express Funded, or Live Funded status wherever automation is armed. If the stage cannot be verified, disable order submission.
A preflight runbook for ProjectX-backed prop accounts
Preflight must verify official rules, permitted device, profile link, account ID, contract ID, risk limits, and full order-state reconciliation.
Start with a dated policy capture: URLs, review date, applicable stage, and the exact restriction governing automation and hosting. Next, authenticate from the permitted device and retrieve accounts. Select one intended account, resolve one current micro contract, and perform a read-only state check. If Topstep currently offers no separate sandbox, follow its direction to use the appropriate Practice account rather than risking an Evaluation account.
Only then exercise the minimum order lifecycle allowed by the account: submit, observe acknowledgement, observe fill or cancellation, and reconcile the resulting position. Test expired authentication, an unknown contract, a duplicate custom tag, HTTP 429 handling, and a lost real-time connection. Stop if the tool cannot prove which account it will trade or if a stage change invalidates the approved path.
- Policy evidence is current and names the exact account stage.
- No private server, VPS, VPN, or relay touches order flow where current rules prohibit it.
- The selected accountId and contractId are discovered, displayed, and allowlisted.
- Quantity and daily exposure remain bounded outside strategy input.
- Order, fill, cancellation, and final position records share one correlation trail.
Sources and methodology
HexTrade Research uses official product, exchange, regulator, and vendor documentation. Policies and platform behavior can change; follow the linked source and verify current terms before trading.
- 1.ProjectX Gateway API documentation — ProjectX, accessed Aug 30, 2026
- 2.ProjectX order placement — ProjectX, accessed Aug 30, 2026
- 3.ProjectX API rate limits — ProjectX, accessed Aug 30, 2026
- 4.TopstepX API access — Topstep, accessed Aug 30, 2026
- 5.Live Funded Account parameters — Topstep, accessed Aug 30, 2026
Frequently asked questions
Is TopstepX the same company or product as ProjectX?
No. For integration purposes, ProjectX provides the gateway technology and API documentation, while TopstepX is Topstep's branded platform and profile experience. Topstep rules remain the authority for Topstep account permission.
Does a ProjectX API subscription allow automation on every Topstep stage?
No. Subscription and technical eligibility do not override account-stage rules. The reviewed Live Funded page says automated trading through the ProjectX API is prohibited in the LFA; verify the current language before deployment.
Can a webhook relay place TopstepX orders from my VPS?
Not under the reviewed Topstep API-access language. It says all trading activity must originate from the personal device and prohibits a remote server from triggering, routing, relaying, placing, modifying, or cancelling orders. Recheck current official rules.
Which platform type should a connector use?
Use the connector's documented ProjectX or TopstepX adapter for the ProjectX Gateway protocol, then select the actual discovered TopstepX account. The exact label is product-specific; never substitute a name for account discovery.
Next step
Put the research into a controlled workflow
Start small, verify the broker and account rules, and keep risk controls between every signal and live order.
See supported brokersContinue reading
Educational content only. Futures are leveraged products and can produce losses greater than the amount you expected to risk. This article is not financial, legal, or prop-firm compliance advice.