Broker API HubMenu

Before you go live: a checklist

A checklist to work through before a script leaves a demo account, with the facts each recorded broker API gives for it. Five questions for every API: which base address is demo and which is live, what limit applies, how a failed request reports itself, what stops a retried order being placed twice, and how you confirm what happened. The answers come from this site's records, in order of name, and where the records are silent the step says not recorded here. None of this is advice to trade, and nothing here has been tested against a live or a demo account.

Independent and unofficialChecked For: Anyone whose script works on a demo account and who is thinking about pointing it at a real one

Risk warning: CFDs and spread bets are complex instruments and come with a high risk of losing money rapidly due to leverage. You can lose money on these products, and each provider publishes its own loss figure under FCA rules. You should consider whether you understand how they work and whether you can afford to take the high risk of losing your money. Automated and API trading can amplify losses through bugs, connectivity failures and runaway orders.

Steps

  1. Capital.com: two hosts, and a confirm call after every order

    Base address: demo is https://demo-api-capital.backend-capital.com/ and live is https://api-capital.backend-capital.com/, so the host is the switch. Limits: Capital.com gives 10 requests a second per user, 1 request per 0.1 seconds for opening positions and orders, 1 request a second per API key on POST /session, and 1,000 requests an hour on demo for POST /positions and POST /workingorders. This site's limits register holds the 10 a second figure with the status verified. Confirming: POST /api/v1/positions returns only a dealReference, and Capital.com says a successful reply does not always mean the position was opened, so read GET /api/v1/confirms/{dealReference} every time. Sessions end after 10 idle minutes. A way to stop a repeated request placing a second order is not recorded here.

    open-api.capital.comchecked

  2. Deriv: one REST host, so check the account type

    Base address: the record holds a single REST address, https://api.derivws.com, for demo and real alike. What separates them is the account: each entry from GET /trading/v1/options/accounts carries an account_type of demo or real, and your code has to read it. Limits: 300 requests a minute and 1,000 in 10 minutes per IP address, and 80 a minute per logged in user, which Deriv says is the one you reach first. The limits register holds the 80 a minute figure with the status verified. Orders: Deriv's trading runs over WebSocket and is not recorded here, so order references, duplicate protection and confirmation are not recorded here either.

    developers.deriv.comchecked

  3. eToro: one host, with demo in the path

    Base address: demo and real share https://public-api.etoro.com. The demo order call is POST /api/v2/trading/execution/demo/orders and the real one is the same path without the word demo, so a missing path segment is the whole difference. This site's record adds that a user key is bound to Demo or Real when it is created. Limits: the order execution calls share a quota of 20 requests in 60 seconds. Retried orders and confirming: every request needs a unique x-request-id, and the reply's referenceId echoes it. eToro describes the header as there for idempotency and for finding the order again if the reply is lost. The record for the real order call notes that a 200 reply means the order was accepted, not that it was executed.

    api-portal.etoro.comchecked

  4. IBKR: answer the question before you assume an order went

    Read in a browser on 12 October 2026. Base address: IBKR's reference lists https://localhost:5000 for the Client Portal Gateway and no separate paper address, so check which username the gateway is logged in with: IBKR says the Web API has no live or paper switch and a paper login uses its own paper username. Limits: 10 requests a second, with lower limits on some endpoints. Confirming: the reply to an order is either an acknowledgement with an order id or an order reply message that must be answered with POST /iserver/reply/{replyId}; IBKR says not to send another order until the previous one is fully acknowledged. Retried orders: each order ticket has an optional cOID field, a client chosen identifier that IBKR says must be unique for a 24 hour span. The reference does not say what happens when a cOID is repeated, so that is not recorded here.

    interactivebrokers.comchecked

  5. IG: two hosts and two sets of credentials

    Base address: demo is https://demo-api.ig.com/gateway/deal and live is https://api.ig.com/gateway/deal. This site's IG quickstart records, from IG's own pages, that demo has its own key and that demo and live credentials cannot be mixed, so moving to live means changing the host and all the credentials together, never one of them. Tokens: IG's guide says CST and X-SECURITY-TOKEN are valid for 6 hours at first, extended up to 72 hours while in use. The record marks that lifetime as conflicting with another IG page, so handle a refused token by logging in again once. Limits: the limits register holds five IG rows, one of them marked conflicting because two IG pages give different figures for trading requests. They are on this site's IG rate limits page at /brokers/ig/rate-limits and are not repeated here.

    labs.ig.comchecked

  6. IG: the deal reference is not a confirmation

    POST /positions/otc replies with a dealReference and nothing else. The record says the deal is not confirmed until you read GET /confirms/{dealReference}, which is where an acceptance or a rejection and its reason appear. IG's reference page also lists an optional dealReference field in the request, a reference of your own of up to 30 characters. That field is noted in the record but not listed among its parameters, and whether IG refuses a repeated reference is not recorded here.

    labs.ig.comchecked

  7. OANDA: two hosts and a published ceiling

    Base address: practice is https://api-fxpractice.oanda.com and live is https://api-fxtrade.oanda.com, with matching stream hosts. Limits: OANDA's development guide gives 120 requests a second per IP address, with HTTP 429 for the excess, no more than 2 new connections a second and 20 active streams. The limits register holds the 120 a second figure with the status verified. A first script is nowhere near that ceiling, but a loop with no pause can be.

    developer.oanda.comchecked

  8. OANDA: read the status code and the reject transaction

    The record for POST /v3/accounts/{accountID}/orders says success is HTTP 201, not 200, so a check for 200 alone reports every good order as a failure. A 400 or 404 reply carries an orderRejectTransaction with an errorMessage, and the 201 reply lists an orderFillTransaction or an orderCancelTransaction when the order was filled or cancelled at once. OANDA's page shows a clientExtensions object with an id of your own on an order. The record does not break out the fields of the order object, so whether that id protects against a repeated request is not recorded here.

    developer.oanda.comchecked

  9. Saxo: limits per session, and a 15 second duplicate window

    Limits: Saxo publishes 120 requests a minute per session per service group, 1 order a second per session and 10,000,000 requests a day per application, with HTTP 429 when one is passed. Replies carry X-RateLimit headers giving the limit, what remains and the seconds until reset. The limits register holds the 120 a minute figure with the status verified. Retried orders: Saxo says an identical operation repeated within a rolling 15 second window is rejected with HTTP 409, and that an x-request-id header with a different value on each request is how you send two identical orders on purpose. Confirming: the place order record says a 200 reply can still carry ErrorInfo, so look for OrderId before treating an order as placed.

    developer.saxochecked

  10. Saxo: simulation and live are separate applications

    Base address: simulation is https://gateway.saxobank.com/sim/openapi with sign in at https://sim.logonvalidation.net, and live is https://gateway.saxobank.com/openapi with sign in at https://live.logonvalidation.net. Saxo says the one day tokens from the developer portal work only in simulation and that live needs an OAuth flow with application credentials that differ between the environments. It also says some functions, such as reporting and market data, are not available in simulation, so a script that passed there has not exercised everything.

    developer.saxochecked

  11. Trading 212: two hosts, and limits counted per account

    Base address: paper trading is https://demo.trading212.com/api/v0 and live is https://live.trading212.com/api/v0, with the same paths on both. Limits: each endpoint has its own limit, applied per account whichever key or IP address is used, and every reply carries x-ratelimit headers with the allowance, what remains and the reset time. The limits register holds the account summary example of 1 request every 5 seconds with the status verified. Read the headers on each reply and pace against the endpoint you are calling.

    docs.trading212.comchecked

  12. Trading 212: an order sent twice may be placed twice

    Trading 212's reference says that in this beta POST /api/v0/equity/orders/market is not idempotent: sending the same request more than once may result in duplicate orders. The order records on this site carry the same warning for the limit, stop and stop limit calls. The reference lists 400 for failed validation, 401 for a bad key, 403 for a key without the orders permission, 408 for a timeout and 429 for the limit. A timeout is the dangerous one, because the order may or may not exist: read the pending orders with GET /api/v0/equity/orders before sending anything again. An order reference of your own is not recorded here.

    docs.trading212.comchecked

Sources

Sections