If you are a developer building an algorithmic trading system, connecting to a forex broker’s API outside the United States is relatively trivial. You open a WebSocket for pricing, POST an order to a REST endpoint, and manage your tickets independently.
If you deploy that exact same code on a US-regulated broker account, it will almost certainly crash, throw a 400 Bad Request, or liquidate the wrong positions.
The US retail forex market is governed by the Commodity Futures Trading Commission (CFTC) and the National Futures Association (NFA). Their compliance rules dictate order routing at the server level, fundamentally breaking how standard algorithmic architectures handle risk management. F
urthermore, the regulatory capital requirements are so high that only five compliant retail brokers remain in the US market.
Refer to this developer’s guide to navigate US execution logic and an architectural audit of the five APIs you can legally build on.
The Code-Breakers: FIFO and No-Hedging
If you are migrating a trading bot from an offshore broker to a US broker, two server-side routing laws will break your logic:
1. The FIFO Mandate (First-In, First-Out)
NFA Rule 2-43(b) dictates that if you have multiple open positions of the exact same size on the same currency pair, the oldest ticket must be closed first.
Imagine your Python script scales into a EUR/USD position at two different price levels:
Ticket_A(Oldest): Long 10,000 unitsTicket_B(Newest): Long 10,000 units
If Ticket_B hits its profit target and your script sends a DELETE /accounts/{accountID}/trades/{Ticket_B}/close request, the US broker's API will reject it. You cannot selectively close a newer ticket.
The Programmatic Workaround: Because FIFO only applies to positions of the exact same size, developers offset their lot sizes by micro-amounts to restore ticket independence.
Entry 1: 10,000 units
Entry 2: 10,001 units
Entry 3: 10,002 units
Because the units differ, the broker's matching engine treats them as distinct liabilities, allowing your script to close them in any sequence.
2. The No-Hedging Rule
You cannot hold simultaneous long and short positions on the same pair. If your script holds a long EUR/USD position and POSTs a sell order for the same pair, the broker's server will not open a new short ticket—it will execute the order by netting (closing) your existing long position.
The 5 Compliant US Broker APIs (2026 Audit)
To ensure I'm building on legal infrastructure, I track active NFA license data using independent directories like BrokerCatalogue. Based on current NFA capital filings, here are the only five compliant retail endpoints, ranked by Developer Experience (DX).
1. OANDA (The v20 REST API)
OANDA has arguably the best developer ecosystem in the retail space. Their v20 REST API is heavily documented, utilizes standard HTTP verbs, and returns clean JSON. They provide officially supported wrappers for Python, Go, and Node.js.
API Protocol: REST, streaming WebSockets for pricing.
Authentication: Personal Access Token (Bearer Auth).
Why Devs Like It: You can spin up a sandbox environment (fxTrade Practice) with fake money and live market data in about three minutes.
Example v20 Order POST:
{
"order": {
"units": "100",
"instrument": "EUR_USD",
"timeInForce": "FOK",
"type": "MARKET",
"positionFill": "DEFAULT"
}
}
2. FOREX.com (StoneX Group)
Backed by StoneX Group, FOREX.com is highly appealing if you need to scale up to institutional infrastructure. They offer a standard REST API for retail accounts, but high-volume systematic traders can request access to their FIX (Financial Information eXchange) API.
API Protocol: REST for retail, FIX 4.4 for high-volume accounts.
Why Devs Like It: If you are building High-Frequency Trading (HFT) algorithms, REST APIs carry too much HTTP overhead. Connecting directly to their FIX API via a VPS located in the Equinix NY4 data center drastically reduces millisecond latency.
3. Interactive Brokers (TWS API & Web API)
Interactive Brokers (IBKR) aggregates liquidity from 17 interbank dealers. The infrastructure is incredibly powerful, but the Developer Experience is notoriously brutal.
API Protocol: TWS API (requires a running instance of their desktop software or IB Gateway), Client Portal REST API, FIX API.
Why Devs Like It: True interbank liquidity. If you are building a multi-asset quantitative system (trading FX, options, and global equities simultaneously), IBKR is the only API that can handle it seamlessly. Just be prepared to fight with their Java/Python wrappers.
4. Charles Schwab (thinkorswim API)
Following the integration of TD Ameritrade, the beloved TD Ameritrade API was migrated to the Schwab Developer portal.
API Protocol: REST.
Why Devs Like It: Access to the thinkorswim ecosystem. While not strictly a forex-first API, it allows developers to pull highly accurate historical tick data and integrate forex positions into broader equity/options portfolios.
5. tastyfx (IG Group REST API)
Formerly known as IG US, tastyfx operates on IG Group's global API infrastructure.
API Protocol: REST for execution, Lightstreamer for live pricing.
Why Devs Like It: They offer over 80 currency pairs (the widest in the US). If you are building a statistical arbitrage bot that relies on obscure minor or exotic pairs, tastyfx provides the necessary market breadth.
Finding the Right API for Your Tech Stack Do not commit to writing a massive codebase until you verify the broker supports the execution model your algorithm requires.
If you need to filter these providers based on API availability, VPS hosting support, and underlying execution models (A-Book vs B-Book), use BrokerCatalogue's interactive Broker Finder Tool. It allows developers to filter the US regulatory landscape dynamically based on verified infrastructure data.
If you are building your first trading bot, start with OANDA's v20 sandbox. If you are migrating a latency-sensitive institutional model, look into FOREX.com's FIX documentation.
Top comments (1)