Broker API HubMenu

Place your first order on a demo account: what every API asks for

What each recorded broker API asks for when you place an order on a demo account, field by field, from this site's endpoint records. Every order call wants the same four answers in different words: which instrument, which direction, how much, and what kind of order. Each step says which fields the record marks as required and where that marking is not confirmed. This is a comparison for learning, in order of name, and none of it is advice to trade.

Independent and unofficialChecked For: Beginners who have made a first read only call and want to understand an order request

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: direction, epic and size

    The record is POST /api/v1/positions, status verified, sent to the demo address https://demo-api-capital.backend-capital.com with the CST and X-SECURITY-TOKEN headers from your session. It marks three body fields as required: direction (BUY or SELL), epic (the instrument) and size. Stops and limits are optional fields. The reply holds only a dealReference, and Capital.com says a successful reply does not always mean the position was opened: you ask GET /api/v1/confirms/{dealReference} for the outcome. The kind of order is settled by the path, since this call deals at market and POST /api/v1/workingorders takes a level and a type of LIMIT or STOP.

    open-api.capital.comchecked

  2. Deriv: not recorded here

    This site holds no order call for Deriv. Deriv's overview says its REST API handles account creation and management, and that trading operations (proposals, buy and sell) run over WebSocket. A WebSocket message has no method and path, so the fields of a Deriv trade are not recorded here. The recorded REST calls stop at listing accounts and fetching a one time WebSocket address.

    developers.deriv.comchecked

  3. eToro: action and transaction, then the instrument and the amount

    The record is POST /api/v2/trading/execution/demo/orders, status verified. The word demo in the path is what makes it a demo order, because demo and real calls share one host. The record marks two body fields as required: action (open or close) and transaction (buy, sell, sellShort or buyToCover). The instrument is given as either instrumentId or symbol, and the size as amount or units. The record lists each of those as not required on its own, and eToro's page says exactly one of symbol or instrumentId is given when opening. The x-request-id header is required and must be unique for each request: the reply's referenceId echoes it, so you can look the order up if the reply is lost.

    api-portal.etoro.comchecked

  4. IBKR: conid, orderType, side, tif and quantity

    Read in a browser on 12 October 2026. IBKR's reference for POST /iserver/account/{accountId}/orders marks the accountId in the path as required and, on each order ticket in the orders list, conid (the instrument), orderType, side (BUY or SELL), tif (how long the order lasts) and quantity. price is optional. The reply is either an acknowledgement with an order id or an order reply message, a question that has to be answered with POST /iserver/reply/{replyId} before the order goes on. IBKR encourages testing with a paper account first, which has its own username.

    interactivebrokers.comchecked

  5. IG: six fields marked required, and a direction

    The record is POST /positions/otc at VERSION 2, status verified, sent to the demo address. It marks six body fields as required because IG's reference marks them not null: epic, size, expiry, currencyCode, forceOpen and guaranteedStop. The record lists direction and orderType as not confirmed as required. On IG's page as opened for this guide, direction carries the same not null marking, so send it. orderType is MARKET, LIMIT or QUOTE. The reference page lists no request headers: the record takes X-IG-API-KEY, CST, X-SECURITY-TOKEN and VERSION from IG's general guide. The reply holds only a dealReference, and the deal is not confirmed until you read GET /confirms/{dealReference}.

    labs.ig.comchecked

  6. OANDA: one order object

    The record is POST /v3/accounts/{accountID}/orders, status verified, sent to the practice host. It marks the Authorization header, the accountID in the path and a single body field named order as required. OANDA calls that object an OrderRequest, and market, limit and stop orders all go through this one call. The fields inside the order object are not broken out in the record, so their required status is not recorded here: read them on OANDA's page. The record's note adds that units are sent as strings, that success is HTTP 201 and not 200, and that a 400 reply carries an orderRejectTransaction saying why.

    developer.oanda.comchecked

  7. Saxo: seven fields, with the required status not confirmed

    The record is POST /trade/v2/orders, status verified, sent to the simulation gateway. It flags seven body fields as required: AccountKey, Uic (the instrument), AssetType, BuySell, Amount, OrderType and OrderDuration. Those flags are this site's reading of Saxo's descriptions and example. Saxo's parameter table has no required column, which was confirmed again when the page was opened for this guide, so treat the required status as not confirmed. A 200 reply is not proof of an order: Saxo says to check the reply for OrderId and ErrorInfo. The record also holds POST /trade/v2/orders/precheck, which takes the same fields and places nothing.

    developer.saxochecked

  8. Trading 212: ticker and a signed quantity

    The record is POST /api/v0/equity/orders/market, status verified, sent to the paper trading host https://demo.trading212.com. Trading 212's reference marks no body field as required, so the record marks none: the fields are ticker, quantity and extendedHours. There is no direction field. A positive quantity buys and a negative quantity sells. Limit, stop and stop limit orders each have their own path and add limitPrice, stopPrice and timeValidity. The reference warns that in this beta the call is not idempotent, so the same request sent twice may place two orders.

    docs.trading212.comchecked

Sources

Sections