TickerAll API Docs

Connect a broker account. We authenticate and warm a live connection, then hand back an accountId — the handle for THIS broker connection. One API key can hold several broker accounts, so the id lives in this response (and in GET /v1/accounts), NOT in the key. Use it in every later /v1/accounts/:id call. By default your password is held in memory only while the connection is live, never saved to disk; the one exception is the opt-in remembered-credentials setting (Pro and Enterprise, PATCH /v1/remember-password), which stores it encrypted solely to restore the connection after a restart.

{
  "accountId": "acc_8Kd3...",
  "isDemo": true,
  "status": "connected",
  "expiresAt": "2026-05-22T18:42:10.000Z"
}

• ▸On Free, demo accounts plus one live account in the Terminal; a live account via the API, SDKs or MCP returns FREE_TIER_LIVE_REJECTED.
• ▸The connection stays warm for a while (see expiresAt). If it cools, calls return BROKER_ACCOUNT_NOT_HOT — just POST /v1/sessions again to reconnect.
• ▸A broker login is linked once. If another of your API keys already holds it where this key cannot see it (an isolated key’s account, or a shared-pool account when this key is isolated), you get 409 BROKER_ACCOUNT_HELD_BY_ANOTHER_KEY and nothing is connected: use the key that owns it, or move it first with POST /v1/accounts/:id/migrate-key. The accountId you get back is always one this key can use.
• ▸If another TickerAll customer already has the login linked, you get 409 BROKER_ACCOUNT_ALREADY_LINKED. It stays linked to them until they remove the account, whether or not it is connected right now.
• ▸On an account with a remembered password you may send no password. If the broker then refuses the remembered one, the 401 BROKER_AUTH_FAILED carries details: { reason: "CREDENTIAL_REJECTED", credentialRejectedAt: "<time>" }, and the account shows the same time in credentialRejectedAt on the next read. A password you send yourself and get wrong is a plain 401 and changes nothing on the account.
• ▸A 401 BROKER_AUTH_FAILED whose body carries details: { reason: "ACCOUNT_NOT_READY", credentialRejected: false } is not a refused password: the broker accepted the login, but the account did not become ready in time. Nothing is marked on the account and a remembered password is kept. The answer says when to retry: details.retryAfterSeconds and a Retry-After header. The wait is 30 seconds the first time and doubles each time the account is again not ready, up to 15 minutes; it starts over once a login succeeds. A connect for the same account sent sooner gets the same answer with the time left, and no new login is attempted; a connect with a different password is tried at once. If it keeps happening, check that the account is active at the broker. The same details are returned by POST /v1/accounts/:id/reconnect and POST /v1/discover.
• ▸Connecting with the current password is how a rejected remembered password is fixed: it replaces the stored one and resets credentialRejectedAt to null on the account.

Disconnect a broker account and release its connection. Returns no body.

(empty body)

• ▸A read-only key may call this for any account it can see: a shared read-only key for accounts in the shared pool, an isolated read-only key for the accounts it owns.

List every broker account attached to your API key, with connection state.

[
  {
    "id": "acc_8Kd3...",
    "broker": "mt5",
    "server": "Exness-MT5Trial14",
    "accountNumber": "****5678",
    "isDemo": true,
    "group": "demo\\Standard",
    "status": "CONNECTED",
    "hot": true,
    "marginMode": "netting",
    "alwaysHot": false,
    "credentialRejectedAt": null,
    "lastHotAt": "2026-05-22T18:30:01.000Z",
    "createdAt": "2026-05-20T09:11:55.000Z"
  }
]

• ▸credentialRejectedAt is always present. null means nothing is wrong. A timestamp means the broker refused the account’s remembered password at that time (for example the password was changed at the broker) — on an automatic reconnect, or on a connect of yours that sent no password — and we stopped retrying it. Connect once with the current password (POST /v1/sessions) to fix it; the field is null again on the next read.
• ▸accountNumber is masked to the last 4 digits.
• ▸hot is the live connection state: true only while the account is connected right now and can be read and traded; false once the connection has cooled or you disconnected it (DELETE /v1/sessions/:accountId) — POST /v1/sessions to reconnect. This is the field to check before a call.
• ▸status on this list is NOT the live connection state. It is the account’s registration state on your roster: "CONNECTED" means the account has connected successfully at least once and is on your roster, and it stays "CONNECTED" while the connection is cold and after you disconnect the session; "PENDING" appears only while a first connection is still in progress. For "is it connected now?" read hot here, or status on GET /v1/accounts/:id, which is the live one ("online" / "offline").
• ▸marginMode is the broker’s margin model for the account — "netting" (one aggregate position per symbol), "hedging" (independent positions per symbol), or "exchange". It is read from the live warm connection, so it is null when the account is cold/offline or on MT4.
• ▸group is the broker’s own account group (e.g. demo\Standard, real\Raw-USD), the best account-type signal available. It is cached per account from the first connection or trade the broker reports it on; null only for an account that has never once been connected.
• ▸Each row carries group and serverTimeOffsetSeconds as last measured on the account (cached across sessions and restarts); null means never seen yet. MT4 accounts carry serverTimeOffsetSeconds too: the value last measured from a live price on the account.
• ▸readOnly is true when the broker reports the login as read-only (an investor password): reads work, and an order, close, modify or cancel answers 409 BROKER_READ_ONLY. It is read from the live connection, so it is null when the account is cold. On MT4 it is true or null — null there means "not known to be read-only".
• ▸Only accounts that connected at least once are listed: a failed connection attempt (unknown server, wrong password, unreachable broker) leaves no entry and does not count toward your plan’s cap.

Live account info — balance, equity, margin, leverage — plus the current open positions.

{
  "id": "acc_8Kd3...",
  "broker": "mt5",
  "server": "Exness-MT5Trial14",
  "accountNumber": "****5678",
  "isDemo": true,
  "credentialRejectedAt": null,
  "status": "online",
  "account": {
    "name": "Demo Account 12345678",
    "accountType": "demo",
    "group": "demo\\Standard",
    "leverage": 500,
    "balance": 9871.42,
    "currency": "USD",
    "equity": 9863.10,
    "margin": 142.50,
    "freeMargin": 9720.60,
    "marginLevel": 6921.5,
    "credit": null,
    "isCent": false,
    "cent": null,
    "serverTimeOffsetSeconds": 0
  },
  "positions": [
    {
      "ticket": 4072808150,
      "symbol": "BTCUSD",
      "side": "BUY",
      "volume": 0.10,
      "entryPrice": 77512.73,
      "stopLoss": 71000,
      "takeProfit": 84000,
      "currentPrice": 77640.10,
      "profit": 12.74,
      "swap": 0,
      "commission": 0,
      "comment": "my-strategy",
      "magic": 0,
      "openTime": "2026-05-22T17:55:03.000Z",
      "brokerOpenTime": "2026-05-22T17:55:03+00:00"
    }
  ]
}

• ▸status here is the live state: "online" when the account is connected and its live figures were read (account and positions are present); "offline" when the connection has cooled or the session was disconnected — the account and positions blocks are then absent, and hot is false; POST /v1/sessions to reconnect. ("offline" with hot: true means the account is connected but its live figures could not be read for this one response — read again.) It is a different field from status on GET /v1/accounts, which is the account’s registration state and reads "CONNECTED" for a cold account too.
• ▸credentialRejectedAt is always present, here and on GET /v1/accounts. null means nothing is wrong. A timestamp means the broker refused the account’s remembered password at that time; the account is then offline, and its data calls (positions, history, candles, …) answer 409 BROKER_ACCOUNT_NOT_HOT with details.reason "CREDENTIAL_REJECTED". One POST /v1/sessions with the current password reconnects it and sets the field back to null.
• ▸Money fields (equity, margin, freeMargin, marginLevel) are null on an MT4 account whenever they cannot be computed at that moment (for example while the account’s open trades are not known yet) — null means "not available", never a misleading 0. credit is null on MT4.
• ▸MT4 accounts, on every login — a trading (master) password and a read-only (investor) password alike: equity, freeMargin and marginLevel, and each open position’s currentPrice and profit, are computed from live prices, on this object, on GET /v1/accounts/:id/positions and in the WebSocket account_update / position_update events. A read-only login shows the same figures as a trading login. They are null (the key is present; never 0) only while a position cannot be valued, for one of two reasons. (1) No price has arrived yet for its symbol — a moment after connect or after the position opens: its currentPrice and profit are null. (2) Its profit cannot be computed — the symbol’s profit currency, or the rate to convert it to the account currency, is not known, or the symbol is a futures-type contract: its profit is null (currentPrice can still be present). A symbol with no profitCurrency on GET /v1/accounts/:id/symbol-specs is always in this case. While any open position is in either state the account’s equity, freeMargin and marginLevel are null too — in case (2) for as long as that position stays open. balance, margin, credit and every other field are unaffected.
• ▸credit: broker-granted credit / deposit bonus in the account currency, already included in equity and freeMargin. A number when the broker reports it (0 means no credit); null only when the broker has not reported a credit figure for the account.
• ▸isCent / cent: whether the account is denominated in a cent unit. The broker reports a cent account’s deposit currency as a cent code — currency "USC" means US cents — and every money field (balance, equity, margin, profit, deal P/L) is in that unit. isCent true comes with cent: { baseCurrency: "USD", unitsPerBase: 100 } (divide by unitsPerBase for dollars); a whole-currency account reads isCent false, cent null; isCent null means the deposit currency is not known yet (no snapshot).
• ▸Each open position carries brokerOpenTime — the same instant as openTime in the broker’s server-local time (RFC 3339 with offset) — on this object and on GET /v1/accounts/:id/positions, whose envelope also carries serverTimeOffsetSeconds. The offset is derived from the account’s open positions as well as its closed deals, so it is known from the first session on any account holding a position.
• ▸serverTimeOffsetSeconds is the broker’s server-local offset from UTC (e.g. 10800 for GMT+3), measured from the broker’s own records. null means it could not be derived yet (no deal or open position on the account); 0 means a UTC server.
• ▸On an MT4 account the connection learns serverTimeOffsetSeconds by itself as it connects — you do not subscribe to anything for it — so on most brokers it is known on the first read. It is learned from the connection’s first price: on some brokers that arrives a few seconds after connect, and on a connection made while the market is closed (a weekend, for example) no price arrives, so it stays null. While the connection does not know it, this object and GET /v1/accounts show the value last measured on an earlier connection (null if there has never been one), and the row lists carry serverTimeOffsetSeconds: null. In that state a time is never the broker’s clock labelled as UTC: open positions read openTime: null with brokerOpenTime set to the broker’s wall-clock time with no offset suffix (e.g. "2026-11-12T11:31:16"), pending orders read setTime: null with brokerSetTime the same way, and the rows of /history, /balance-operations and /orders-history read their UTC times as null with the broker* twin set the same way (those responses carry timeBasis: "broker"). Candles keep their timestamps on the broker’s server clock and say so with timeBasis: "broker". Once the offset is known (0 counts as known) everything is UTC with twins, like MT5.
• ▸group is the broker’s own account group (e.g. demo\Raw-USD, real\Standard) — the best account-type signal the broker exposes. The broker sends it on an account’s first connection and on trade events; TickerAll caches it per account from that point, so it is present on the account object and the WebSocket snapshot on every later session and survives reconnects and maintenance. The only time it is null is an account that has never once been connected — never a made-up value.

The account’s current open positions — the dedicated positions feed. Each row carries entry price, volume, live P&L and SL/TP; it is the same array GET /v1/accounts/:id embeds, with a brokerOpenTime twin per row and serverTimeOffsetSeconds on the envelope.

{
  "accountId": "acc_8Kd3...",
  "positions": [
    {
      "ticket": 4072808150,
      "symbol": "BTCUSD",
      "side": "BUY",
      "volume": 0.10,
      "entryPrice": 77512.73,
      "stopLoss": 71000,
      "takeProfit": 84000,
      "currentPrice": 77640.10,
      "profit": 12.74,
      "swap": 0,
      "commission": 0,
      "comment": "my-strategy",
      "magic": 0,
      "openTime": "2026-05-22T17:55:03.000Z",
      "brokerOpenTime": "2026-05-22T17:55:03+00:00"
    }
  ],
  "serverTimeOffsetSeconds": 0
}

• ▸An empty positions array is valid data — it means no open positions, never an error.
• ▸entryPrice is the position’s actual fill price; currentPrice and profit are live and move with the market. profit is in the account’s deposit currency.
• ▸MT4 accounts: currentPrice and profit are computed from live prices on every login — a read-only (investor password) login shows the same figures as a trading login — and are normally there on the first read after connect and on the first read after a position opens. Either is null (the key is present; never 0) only while the position cannot be valued: no price has arrived yet for its symbol (a moment after connect or after the open), or its profit cannot be computed (the symbol’s profit currency, or the rate to convert it to the account currency, is not known, or the symbol is a futures-type contract) — then profit is null while currentPrice can still be present; a symbol with no profitCurrency on GET /v1/accounts/:id/symbol-specs is always in this case. While any open position is in that state the account’s equity, freeMargin and marginLevel are null as well. Every other field of the row is as usual.
• ▸magic is the EA (Expert Advisor) magic number the trade was opened with — the integer a bot stamps its orders with; 0 means a manual or non-EA trade (0 is a real value, not "missing"). The same field is on pending orders.
• ▸openTime is UTC; brokerOpenTime is the same instant in the broker’s server-local time (RFC 3339 with offset). serverTimeOffsetSeconds on the envelope is the broker’s offset from UTC (e.g. 10800 for GMT+3); null means it could not be derived yet, 0 means a UTC server.
• ▸MT4 only, while serverTimeOffsetSeconds is null (the first few seconds after connect on some brokers, or a connection made while the market is closed): openTime is null — it is never the broker’s clock labelled as UTC — and brokerOpenTime carries the broker’s wall-clock time with no offset suffix, e.g. "2026-11-12T11:31:16". Once the offset is known (0 counts as known) openTime is UTC and brokerOpenTime has its offset again. The WebSocket position_update events follow the same rule.
• ▸The same positions are also on GET /v1/accounts/:id alongside the money fields — use this lighter call when you only need positions, and subscribe to the positions WebSocket channel for live updates.

Remove a broker account from your roster. We disconnect its live connection and drop it from your account list and from billing — this does NOT touch the broker account itself or any open positions. Reversible: reconnect the same login with POST /v1/sessions to re-add it.

{
  "id": "acc_8Kd3...",
  "status": "DISCONNECTED",
  "removed": true,
  "existed": true,
  "billableCount": 0
}

• ▸Idempotent — removing an already-removed or unknown id returns the same 200 shape (a retried cleanup never fails half-way). existed tells them apart: true when a linked account was actually removed by this call, false when nothing was linked under that id (a typo, or already gone). An id that belongs to another customer is a 404.
• ▸If the account had always-hot enabled, that per-connection charge stops immediately; billableCount is your remaining always-hot connection count.
• ▸If the account has a remembered password (see /v1/remember-password), it is destroyed before the account is removed. If our vault can’t confirm that yet, you get 503 VAULT_PURGE_PENDING and the account stays linked; retry the DELETE.
• ▸A read-only key may remove any account it can see: a shared read-only key the accounts in the shared pool, an isolated read-only key the accounts it owns.

Switch which terminal type the account presents AS ("MOBILE" or "WEB"). Your open positions, pending orders and balance live on the broker account, not the connection, so they are preserved across the switch.

{
  "id": "acc_8Kd3...",
  "terminalType": "MOBILE",
  "status": "noop"
}

• ▸status is "noop" when the account is already on the requested transport.
• ▸Switching runs only when the account is idle (no in-flight trade — otherwise 409).
• ▸Both terminal types expose the full surface (account, quotes, positions, history).
• ▸The switch is zero-gap — the new transport is warmed before the old session is dropped — so open positions, orders and balance carry over untouched.

Move a broker account between the shared pool and an isolated API key, in place. Pass an isolated API key id to move the account under that key (only that key, plus the dashboard, then sees it), or null to move it back to the shared pool. The connection is never dropped — a warm account stays warm, positions/orders/balance untouched.

{
  "id": "acc_8Kd3...",
  "ownerApiKeyId": "key_7Qf2...",
  "isolated": true,
  "hot": true,
  "migrated": true
}

• ▸ownerApiKeyId in the response is the new owner: null = shared pool, else the isolated key id. isolated mirrors it.
• ▸migrated is false when the account was already where you asked (a no-op).
• ▸hot reflects the live connection — migration never drops it, so a warm account stays warm.
• ▸Only the shared pool ↔ an isolated key are valid moves; moving directly between two isolated keys is rejected (migrate to the shared pool first).
• ▸The account now also carries ownerApiKeyId on GET /v1/accounts and GET /v1/accounts/:id.
• ▸Requires a full (non read-only) key; via an API key, the only isolated target is the calling key itself — naming another key id requires the dashboard.

Keep one account’s connection warm 24/7: skips the idle cool-down so the session stays up between your calls. Broker-side drops reconnect automatically on every account regardless; always-hot only removes the idle timeout. Off by default. Trader ($0.99/mo per connection) or Pro / Enterprise (included).

{
  "id": "acc_8Kd3...",
  "alwaysHot": true,
  "effective": true,
  "appliedLive": true,
  "billableCount": 1
}

• ▸effective is the resolved state (this flag OR the account-wide switch, on an eligible plan). appliedLive is true when the account was warm and the change took effect on the live session immediately; a cold account applies it on its next connect.
• ▸What always-hot does NOT do: it does not store your password. If TickerAll itself restarts, the account returns as needs-rearm (see GET /v1/always-hot/pending) until you POST /v1/sessions again — unless you opt in to remembered credentials.
• ▸403 ALWAYS_HOT_TIER_REQUIRED on the Free plan.
• ▸A read-only key may switch it, on or off, for any account it can see: a shared read-only key for accounts in the shared pool, an isolated read-only key for the accounts it owns.

Account-wide always-hot: every eligible connection defaults to warm. Same semantics as the per-account toggle, applied live to all held sessions.

{
  "accountWide": true,
  "billableCount": 3
}

• ▸403 ALWAYS_HOT_TIER_REQUIRED on the Free plan.

Always-hot accounts that currently have no live connection and need a credentials refresh — typically after a TickerAll maintenance restart dropped the in-memory password. Empty means nothing needs attention.

{
  "pending": [
    { "id": "acc_8Kd3...", "broker": "mt5", "server": "Exness-MT5Trial14", "accountNumber": "****5678" }
  ]
}

• ▸Re-arm an account by calling POST /v1/sessions with its credentials again. The TypeScript and Python SDKs do this for you: sessions.keepAlive() / keep_alive() caches the credentials in your process and re-arms a cold account on its next call.
• ▸If you cannot keep credentials on your side at all, see PATCH /v1/remember-password — with it on, accounts that are always-hot re-arm themselves server-side and never appear here.

Status of remembered credentials — the one opt-in exception to TickerAll’s rule of never storing broker passwords. Available on Pro and Enterprise, for customers who cannot keep credentials on their own side.

{
  "accountWide": false,
  "eligible": true,
  "tier": "PRO",
  "remembered": 0,
  "armed": 0
}

• ▸remembered = accounts whose password is sealed in the vault; armed = opted in but not yet captured (the password is captured on each account’s next connect, never through this endpoint).
• ▸eligible is false on the Free and Trader plans.

Turn remembered credentials on or off for ALL your accounts. On: each account’s password is sealed in an encrypted vault (AES-256-GCM) on its next connect and used solely to restore the connection after a TickerAll restart; your consent text is recorded. Off: every stored password is purged immediately.

{
  "accountWide": true
}

• ▸Off by default on every plan; nothing is stored until you switch it on. Turning it off returns { "accountWide": false, "forgotten": <n> } after rotating every sealed secret to an unreadable value and clearing the flags.
• ▸Once on, an account that is also always-hot re-arms itself server-side after a maintenance restart — no POST /v1/sessions needed. If you can supply the password yourself on reconnect, leave it off.
• ▸A password you pass to POST /v1/sessions on a remembered account updates the stored one; on a remembered account you may also omit password to reconnect.
• ▸403 REMEMBER_PRO_REQUIRED below Pro.

Choose remembered credentials for ONE account, overriding the account-wide setting. on: remember this account’s password even with the account-wide switch off. off: never remember it, even with the switch on, and destroy what is stored now. inherit: follow the account-wide switch again.

{
  "id": "cmabc123",
  "rememberChoice": "off",
  "effective": false,
  "stored": false,
  "pendingPurge": 0
}

• ▸effective = whether this account is remembered once both settings are applied. stored = a password is sealed in the vault right now (for on, it is captured on the account’s next connect, never through this endpoint).
• ▸pendingPurge = 1 when the vault could not confirm the password was destroyed; retry the same call. off is available on every plan; on is Pro and Enterprise (403 REMEMBER_PRO_REQUIRED).
• ▸Turning the account-wide switch off resets every on to inherit, so it purges everything. An off set here survives turning the switch back on.

List tradeable symbols on the account, in the broker’s native names (pass-through, no normalization). symbols is the full catalog; watched is the subset that is actively streaming live ticks right now.

{
  "symbols": ["BTCUSD", "ETHUSD", "EURUSD", "GOLD", "USOILm", "..."],
  "watched": ["BTCUSD", "ETHUSD", "EURUSD"]
}

• ▸Use a name from symbols when placing orders; subscribe to a name to start it ticking on the WebSocket.
• ▸symbols is never legitimately empty on a connected account. If TickerAll cannot read the account’s instrument list you get 503 SYMBOL_CATALOG_UNAVAILABLE rather than an empty array — so an empty list can never be mistaken for “no symbols” or for an account-type verdict.

Per-symbol trading specs for the account: the volume constraints (min / max / step) for validating an order size before placing it, the price geometry (digits, point, tickSize) and contract maths (contractSize, tickValue, tickValueAccount) for sizing risk per tick, the broker’s stop and freeze levels, and the base, profit (quote) and margin currency for each instrument. Available on MT4 and MT5; see the note on which MT4 values are typical rather than broker-published.

{
  "specs": [
    {
      "name": "EURUSD",
      "volumeMin": 0.01,
      "volumeMax": 200.0,
      "volumeStep": 0.01,
      "specSource": "broker",
      "digits": 5,
      "point": 0.00001,
      "tickSize": 0.00001,
      "contractSize": 100000,
      "tickValue": 1.0,
      "tickValueAccount": 1.0,
      "tickValueCurrency": { "code": "USD", "source": "wire" },
      "stopLevel": 0,
      "freezeLevel": 0,
      "baseCurrency": "EUR",
      "profitCurrency": "USD",
      "marginCurrency": "EUR"
    }
  ]
}

• ▸volumeStep is the lot increment — round an order size down to it before placing; volumeMin / volumeMax bound the size.
• ▸profitCurrency is the quote currency (the currency P&L accrues in). Use it — not the account currency — to denote an instrument.
• ▸On MT4, profitCurrency is the quote currency of the symbol (BTCUSD → "USD", GBPJPY → "JPY"); for an instrument that is not a currency pair it is the margin currency. marginCurrency is the currency the broker holds margin in (BTCUSD → "BTC"). MT4 brokers do not publish volume limits, so volumeMin / volumeMax / volumeStep are typical values for the instrument type and specSource is "derived".
• ▸MT4 rows also carry executionMode — "market", "instant" or "request" (how the broker executes market orders on the symbol), or null when it is not known. Market orders and closes on an "instant" or "request" symbol cannot be placed through the API yet: they answer 422 TRADE_DISABLED and nothing is sent to the broker; pending orders and SL/TP changes are unaffected. The field is absent on MT5.
• ▸specSource is "broker" (authoritative) or "derived" (a best-effort fallback when the broker did not supply the spec). Currency fields are absent when unknown.
• ▸Price geometry: digits is the quote precision, point is the smallest price increment (10^-digits), and tickSize is the smallest price change the broker accepts — equal to point on every instrument we serve. Use tickSize, not a hard-coded 0.0001 / 0.01, to step a price.
• ▸Tick value: tickValue is the profit-currency value of a one-point move on 1.00 lot (contractSize x point). tickValueAccount is that same figure converted into the ACCOUNT’s deposit currency, and tickValueCurrency tells you which currency it is in plus where it came from — source "wire" (read from the broker), "heuristic" (derived by us) or "override".
• ▸Size risk off tickValueAccount, not tickValue: risk = |entry - stop| / tickSize * tickValueAccount * lots. tickValue is in the instrument’s profit currency, which differs from your deposit currency on many symbols — using it directly overstates or understates risk by the cross-rate.
• ▸Absent means UNKNOWN, never zero. Any of digits, point, tickSize, contractSize, tickValue, tickValueAccount and the currency fields is omitted entirely when the broker’s record did not carry it, so you can tell "unknown" from a real 0 and fall back deliberately. Do NOT default a missing tickValueAccount to contractSize * tickSize — that is the profit-currency figure and is wrong whenever the profit currency is not your deposit currency.
• ▸stopLevel and freezeLevel are in POINTS, and 0 is real data meaning no restriction (common on floating-spread symbols) — not a missing value. stopLevel is the minimum distance an SL / TP must keep from the current price; inside freezeLevel the broker refuses modifications. Checking stopLevel before a PATCH turns most 422 BROKER_REJECTED stop-distance rejections into a client-side check.

The full trading spec for ONE symbol — the same object GET /v1/accounts/:id/symbol-specs returns per entry, for a single instrument. Cheaper than the full list when you only need the contract maths for the symbol you are about to trade: a warm account answers from its cached catalog. Available on MT4 and MT5.

{
  "spec": {
    "name": "EURUSD",
    "volumeMin": 0.01,
    "volumeMax": 200.0,
    "volumeStep": 0.01,
    "specSource": "broker",
    "digits": 5,
    "point": 0.00001,
    "tickSize": 0.00001,
    "contractSize": 100000,
    "tickValue": 1.0,
    "tickValueAccount": 1.0,
    "tickValueCurrency": { "code": "USD", "source": "wire" },
    "stopLevel": 0,
    "freezeLevel": 0,
    "baseCurrency": "EUR",
    "profitCurrency": "USD",
    "marginCurrency": "EUR"
  }
}

• ▸Field meanings, units and the absent-means-unknown contract are identical to GET /v1/accounts/:id/symbol-specs — see its notes, including the risk formula and the warning against defaulting tickValueAccount.
• ▸A symbol the account has never touched is primed once and then read, so the first call for it can be slower than subsequent ones.
• ▸An unknown symbol on this account is a 404 — distinct from a known symbol with fields missing, which is a 200 with those fields absent.

The current live bid and ask for one symbol. Candles are bid-only, so this is the way to read the ASK over REST — needed to compute a spread or to place a limit relative to the offer. MT5 only; an MT4 account returns 404.

{
  "symbol": "EURUSD",
  "bid": 1.07241,
  "ask": 1.07249
}

• ▸bid and ask are null — never 0 — when the symbol exists but is not currently quoted, e.g. a closed market. That is an honest "no live price", distinct from an unknown symbol (404).
• ▸A symbol the account is not already streaming is subscribed once and polled briefly for its first tick, so the first call can take a moment; a watched symbol answers from the last tick immediately.
• ▸The response carries no tick time — it is the latest tick as of the request. If you need to stamp a price, use your own receive time, or the WebSocket stream.
• ▸For continuous prices use the WebSocket rather than polling this endpoint.

Fetch historical OHLC bars from your connected broker, for any symbol the broker streams on this account. Two modes: a look-back window (hours) returns the most-recent N hours of bars, or a date range (from + to, ISO-8601) returns the exact [from, to] window. Coarser timeframes (H4, D1, W1, MN1) reach much further back — daily bars typically cover years of history. Every response reports how much of the requested window was actually served (coverage / truncated).

{
  "symbol": "BTCUSD",
  "hours": 17520,
  "timeframe": "D1",
  "candles": [
    { "timestamp": 1747699200, "open": 104200.10, "high": 107840.55, "low": 103520.00, "close": 106910.73, "bid": 106910.73 },
    { "timestamp": 1747785600, "open": 106910.73, "high": 108100.00, "low": 105480.20, "close": 107512.40, "bid": 107512.40 }
  ],
  "served": { "from": "2025-05-20T00:00:00.000Z", "to": "2025-05-21T00:00:00.000Z" },
  "count": 2,
  "coverage": "complete",
  "truncated": false,
  "stopReason": "floor"
}

• ▸Authed — needs your API key (same as the rest of the customer API). Works for any symbol your broker exposes on the connected account.
• ▸Two modes: pass hours for a look-back window, OR pass both from and to for an exact date range. When from and to are present, hours is ignored, and the response echoes from/to (the requested window, as ISO-8601) at the top level instead of hours. Supplying only one of from/to, a value that cannot be read, or from ≥ to returns 400 invalid_range; the message names the accepted formats and gives an example.
• ▸from / to formats, on every account type: ISO-8601, Unix seconds, or Unix milliseconds (a digits-only value below 1,000,000,000,000 is read as seconds). A digits-only value shorter than 9 digits is not read as a time and is a 400 — a year or a date written without separators (2026, 20261109) would otherwise be taken for a moment in 1970; write the date as 2026-11-09. The one exception is 0, the Unix epoch. Worked example — the same 12-hour window three ways: ?symbol=EURUSD&timeframe=M5&from=2026-11-09T00:00:00Z&to=2026-11-09T12:00:00Z, or &from=1794182400&to=1794225600, or &from=1794182400000&to=1794225600000. A bare date is the start of that day in UTC, so from=2026-11-09&to=2026-11-10 is the whole of 9 November.
• ▸An empty candles list with 200 means there are no bars in that range — it is not an error. The usual cause is a closed market: hours=24 on a Sunday has no bars for a symbol that last traded on Friday. The range you asked for is the range you get; older bars are never substituted. Ask for a wider window (hours=96) or an explicit from/to to reach the last session.
• ▸MT4 accounts serve the bars the connection holds: M5 bars from the broker’s recent chart data where the broker provides it; otherwise bars (M1 to D1) built from the symbol’s live prices. Those start at the first live price received after the symbol begins to be watched on this connection — which happens when you subscribe to its ticks on the WebSocket, or on your first candles request for it — not when the account connected. So the first candles request for a symbol nobody is streaming returns no bars and starts the collection; later requests return the bars formed since. hours is counted back from the broker’s current time. Any window, short or long, that starts before the oldest held bar returns what exists with coverage "partial", truncated true and stopReason "unsupported"; a window the held bars fully cover is "complete". W1 and MN1 are not available on MT4.
• ▸MT4 only: when the account’s serverTimeOffsetSeconds is not known yet, the response adds timeBasis: "broker" and a timeBasisNote — the timestamps are then in the broker’s server time and the hours window was counted from UTC. The field is absent in every other case.
• ▸Each candle is { timestamp, open, high, low, close, bid, tickVolume, spread }. timestamp is the bar OPEN time in Unix seconds, in UTC: the broker stamps bars on its own server clock and TickerAll has already subtracted the broker’s clock offset, so do not subtract serverTimeOffsetSeconds yourself (the response carries no offset field). The offset applied is the one in force now — bars from before the broker’s last daylight-saving change are one hour off — and until it is known on a session (no price received yet) bars come back on the broker’s server clock, which an MT4 account marks with timeBasis: "broker". The same holds for MT4 and MT5 accounts. bid mirrors close. tickVolume (tick count) and spread (price units) are present on recent bars; deep-history bars are bid-only and may omit them (null/absent) — don’t rely on a guaranteed volume.
• ▸Every response also reports completeness: served ({ from, to } actually returned in ISO-8601, or null when empty), count (number of candles), coverage ("complete" when the whole window was served, otherwise "floor"/"partial"), truncated (boolean — true when the whole requested window was NOT served; the authoritative completeness signal), and stopReason (why the walk stopped, e.g. "floor" = no deeper data exists, "deadline" = worth retrying, "unsupported", "error"). A note field is added when stopReason is "unsupported".
• ▸A range larger than the per-request cap (~5 years, or ~100,000 bars at the chosen timeframe) is rejected with 400 range_too_large ({ maxBars, estimatedBars, maxWindowDays }) — narrow the range or coarsen the timeframe.
• ▸Timeframes: M1, M5, M15, M30, H1, H4, D1, W1, MN1. Daily and coarser reach back years; intraday (M1–H4) covers recent months. One request returns as much history as fits in a few seconds. Deep look-backs are isolated onto a dedicated history connection — a big walk never disturbs your live tick stream.
• ▸If the broker returns no decodable bars for the symbol/range (e.g. an illiquid pair), the response is a 200 with an empty candles array (served null, truncated true) — never a 500.

Unauthenticated read of the always-on demo feed — powers the sparklines and chart on tickerall.com. Limited to TickerAll’s demo symbol list and only callable from tickerall.com (origin-gated). For arbitrary broker symbols from your own code, use GET /v1/accounts/:id/candles above.

{
  "symbol": "BTCUSD",
  "hours": 17520,
  "timeframe": "D1",
  "candles": [
    { "timestamp": 1747699200, "open": 104200.10, "high": 107840.55, "low": 103520.00, "close": 106910.73, "bid": 106910.73 },
    { "timestamp": 1747785600, "open": 106910.73, "high": 108100.00, "low": 105480.20, "close": 107512.40, "bid": 107512.40 }
  ]
}

• ▸No API key needed, but origin-gated: this endpoint accepts requests from tickerall.com only and exists to drive the public demo widgets. For programmatic access from your own code use GET /v1/accounts/:id/candles instead — it works on any symbol your broker exposes.
• ▸Each candle is { timestamp, open, high, low, close, bid }. timestamp is the bar OPEN time in Unix seconds, in UTC: the broker stamps bars on its own server clock and TickerAll has already subtracted the broker’s clock offset (the one in force now, so bars from before the broker’s last daylight-saving change are one hour off). bid mirrors close.
• ▸Only the demo feed’s symbol list is available here. For any other symbol, connect a broker account and call GET /v1/accounts/:id/candles instead.

Place a market order (fills immediately) or a pending limit/stop order (rests until price is hit).

{
  "ticket": 4072808150,
  "symbol": "BTCUSD",
  "side": "BUY",
  "type": "market",
  "volume": 0.10,
  "price": null,
  "stopLoss": 71000,
  "takeProfit": 84000,
  "comment": "my-strategy",
  "status": "open",
  "timestamp": "2026-05-22T17:55:03.000Z"
}

• ▸Requires an Idempotency-Key header (see Conventions). Re-sending the same key returns the original response without placing a second order.
• ▸Pending orders are expressed as two separate fields, not one combined name: a buy-stop is type:"stop" + side:"BUY"; a sell-limit is type:"limit" + side:"SELL". The write API does NOT accept MetaTrader-style combined names (BUY_STOP, SELL_LIMIT, …) — passing type:"BUY_STOP" is a 400 VALIDATION_ERROR. GET /v1/accounts/:id/orders reports that combined name in its own type field for readability, but that is a read-only convenience: do not echo it back here — use its orderType (LIMIT/STOP) lowercased as type, plus side.
• ▸status is "open" for market orders and "pending" for limit/stop orders.
• ▸A broker rejection (bad volume, market closed, stop-level too tight, insufficient margin) comes back as 422 BROKER_REJECTED with the broker’s reason in message.
• ▸Pending orders are placed good-till-cancelled and there is no expiry field on this call. An expiry you cannot set is better than one silently ignored: nothing here accepts an expiration time, so a pending order rests until it triggers or you cancel it with DELETE /v1/accounts/:id/orders/:ticket.

List the account’s working pending orders — LIMIT and STOP orders resting until their trigger price is hit. A market order is never pending: it becomes an open position immediately (see GET /v1/accounts/:id/positions). Returns an empty list when nothing is resting.

{
  "orders": [
    {
      "ticket": "4072809988",
      "symbol": "BTCUSD",
      "type": "BUY_LIMIT",
      "side": "BUY",
      "orderType": "LIMIT",
      "volume": 0.10,
      "price": 68000,
      "limitPrice": null,
      "stopLoss": 66000,
      "takeProfit": 72000,
      "setTime": "2026-08-14T09:12:44.000Z",
      "expirationTime": null,
      "comment": "",
      "magic": 0
    }
  ]
}

• ▸magic is the EA (Expert Advisor) magic number the order was placed with — the integer a bot stamps its orders with; 0 means a manual or non-EA order (0 is a real value, not "missing"). comment is the order comment set at placement, "" when none.
• ▸Working (pending) orders only. When a pending order triggers it leaves this list and becomes an open position — find it under GET /v1/accounts/:id/positions.
• ▸MT4 and MT5 accounts return the same row. MT4 has limit and stop orders only (no stop-limit), so limitPrice is always null there.
• ▸MT4 only, while the account’s serverTimeOffsetSeconds is null (the first few seconds after connect on some brokers, or a connection made while the market is closed): setTime is null and the row carries brokerSetTime — the broker’s wall-clock time with no offset suffix, e.g. "2026-11-12T11:31:16". An order that has an expiration then reads expirationTime: null with brokerExpirationTime set the same way, so in that state check brokerExpirationTime before reading null as good-till-cancelled. Once the offset is known (0 counts as known) setTime and expirationTime are UTC and the two broker fields are absent. The WebSocket order_update events carry the same rows.
• ▸type is one of BUY_LIMIT, SELL_LIMIT, BUY_STOP, SELL_STOP, BUY_STOP_LIMIT, SELL_STOP_LIMIT; orderType collapses that to LIMIT / STOP / STOP_LIMIT and side to BUY / SELL. ticket is a string; price is the trigger (activation) level; limitPrice is set only on STOP_LIMIT variants; expirationTime is null for good-till-cancelled.
• ▸Expiry is READ-ONLY today. Every pending order placed through this API is good-till-cancelled, so expirationTime is null on anything you placed here; a non-null value means the order was created elsewhere (your terminal) with an expiry. There is no expiry field on POST /v1/accounts/:id/orders or PATCH /v1/accounts/:id/orders/:ticket — expiry is not accepted and therefore never silently dropped. Cancel explicitly with DELETE /v1/accounts/:id/orders/:ticket when you need a time-bounded order.
• ▸This combined type (e.g. BUY_STOP) is READ-ONLY. To place or modify an order, use the split form — type (market/limit/stop) + side (BUY/SELL) — from POST /v1/accounts/:id/orders; the write API does not accept BUY_STOP-style names.
• ▸For live updates instead of polling, subscribe to the orders channel over the WebSocket (see the WebSocket section) — it pushes the full pending-order list on subscribe and on every change.
• ▸Optional ?waitMs=<0–10000> adds a settle window for a just-warmed connection’s first pending snapshot; omit for an immediate read.
• ▸Also reachable at the alias GET /v1/accounts/:id/orders/pending.

Cancel a resting pending order (LIMIT or STOP) by its ticket.

{
  "ticket": 4072809988,
  "symbol": "BTCUSD",
  "side": "BUY",
  "cancelled": true,
  "timestamp": "2026-08-14T09:12:44.000Z"
}

• ▸Requires an Idempotency-Key header.
• ▸ticket is the pending order’s ticket from GET /v1/accounts/:id/orders — not a position. If the order has already triggered it is now an open position; close it with DELETE /v1/accounts/:id/positions/:ticket instead.
• ▸If the ticket is not a resting pending order on this account you get 404 TICKET_NOT_FOUND.
• ▸Works on MT4 and MT5 accounts. ticket is the number in the order’s ticket field (a string in GET /v1/accounts/:id/orders, a number in the URL).

Modify a resting pending order’s trigger price, stop-loss or take-profit. Any field you omit is preserved at its current value.

{
  "ticket": 4072809988,
  "symbol": "BTCUSD",
  "side": "BUY",
  "price": 66000,
  "stopLoss": 64000,
  "takeProfit": 72000,
  "timestamp": "2026-08-14T09:12:44.000Z"
}

• ▸Requires an Idempotency-Key header.
• ▸Provide at least one of price, stopLoss or takeProfit — an empty body is a 400. Omitted fields keep their current value.
• ▸If the ticket is not a resting pending order on this account you get 404 TICKET_NOT_FOUND.
• ▸As on an open position, send stopLoss or takeProfit as 0 to REMOVE that level rather than move it; omitting the field keeps it. The trigger price is different — price must be a positive number, since a resting order has nowhere to trigger without one.
• ▸This call changes the trigger price, SL and TP only — it cannot set or remove an expiry. See GET /v1/accounts/:id/orders on expiry being read-only.

Cancel every resting pending order on the account in one call, optionally narrowed by symbol, side and/or type. The server lists the pending orders once and cancels the matches in parallel.

{
  "results": [
    { "ticket": 4072809988, "symbol": "BTCUSD", "side": "BUY", "status": "ok", "cancelled": true },
    { "ticket": 4072809991, "symbol": "BTCUSD", "side": "SELL", "status": "failed", "code": "BROKER_REJECTED", "reason": "Broker rejected the cancel." }
  ],
  "summary": { "requested": 2, "ok": 1, "failed": 1 }
}

• ▸Requires an Idempotency-Key header.
• ▸Body (all fields optional): { "symbol": "EURUSD", "side": "BUY", "type": "limit" }. type is one of limit / stop / stopLimit; side is BUY / SELL.
• ▸Single-account cancel — for a ticket you already hold use DELETE /v1/accounts/:id/orders/:ticket; to cancel across many accounts at once use POST /v1/bulk/orders/cancel.
• ▸Always 200. No matching pending orders is an empty success — results: [] with summary { requested: 0, ok: 0, failed: 0 } — never a 404 or an error.
• ▸Partial success — each order’s outcome is in results: status "ok" (cancelled true) or "failed" (with a code and reason). summary tallies requested / ok / failed.
• ▸Works on MT4 and MT5 accounts.

Close an open position. Omit volume for a full close, or pass a smaller volume for a partial close.

{
  "ticket": 4072808150,
  "symbol": "BTCUSD",
  "side": "BUY",
  "volume": 0.10,
  "closed": true,
  "timestamp": "2026-05-22T18:10:44.000Z",
  "closePrice": 81320.15,
  "dealTicket": "1191098644",
  "profit": -0.40,
  "swap": 0,
  "commission": 0
}

• ▸Requires an Idempotency-Key header. Re-using a key with a different body or ticket is a 409 IDEMPOTENCY_KEY_REUSED — nothing is replayed or executed.
• ▸If the ticket is not an open position on this account you get 404 TICKET_NOT_FOUND.
• ▸closePrice, dealTicket, profit, swap and commission are the booked closing deal — the same values the OUT row in /deals-history carries (dealTicket is its ticket there; money in the account currency). They are null when the broker has not booked the deal by the time the response is sent (rare — read /deals-history then); 0 is a real 0. A partial close reports the deal for the closed part.
• ▸On MT4, closePrice, profit, swap and commission come from the broker’s record of the closed trade (profit is before swap and commission). dealTicket is always null — an MT4 trade has one ticket, the one in the URL. If the broker’s record does not arrive within about 2.5 seconds, those four are null; GET /v1/accounts/:id/history lists the closed trade once it has.
• ▸On MT4 a PARTIAL close ends the ticket you closed: the part still open continues under a NEW ticket. The response then carries remainderTicket — that new ticket, or null when it is not known yet (read GET /v1/accounts/:id/positions; the broker marks it with the comment "from #<old ticket>"). The field is absent on a full close and on MT5, where a position keeps its ticket.
• ▸volume is what was actually closed. Asking for more than is open closes the whole position (the contract is unchanged) and the response then also carries requestedVolume, warningCode "VOLUME_CLAMPED" and a warning message; these three fields are absent otherwise.

Flatten the account — close every open position in one call, optionally narrowed by symbol and/or side. The server reads the account’s open positions once and closes the matches in parallel.

{
  "results": [
    { "ticket": 4072808150, "symbol": "BTCUSD", "side": "BUY", "status": "ok", "closed": true, "closePrice": 81320.15, "dealTicket": "1191098644", "profit": -0.40, "swap": 0, "commission": 0 },
    { "ticket": 4072809002, "symbol": "BTCUSD", "side": "SELL", "status": "failed", "code": "BROKER_REJECTED", "reason": "Broker rejected the close." }
  ],
  "summary": { "requested": 2, "ok": 1, "failed": 1 }
}

• ▸Requires an Idempotency-Key header.
• ▸Body (all fields optional): { "symbol": "EURUSD", "side": "BUY" }. side is BUY / SELL.
• ▸Each "ok" result carries the booked closing deal (closePrice, dealTicket, profit, swap, commission), null when not yet booked — the same fields as a single DELETE.
• ▸Single-account flatten — for a ticket you already hold use DELETE /v1/accounts/:id/positions/:ticket; to flatten across many accounts at once use POST /v1/bulk/positions/close.
• ▸Always 200. No matching positions is an empty success — results: [] with summary { requested: 0, ok: 0, failed: 0 } — never a 404 or an error.
• ▸Partial success — each position’s outcome is in results: status "ok" (closed true) or "failed" (with a code and reason). summary tallies requested / ok / failed.
• ▸Each "ok" result carries the booked close deal (closePrice, dealTicket, profit, swap, commission), as on the single close; null until the broker books it.

Modify the stop-loss and/or take-profit of an open position, or remove one. Provide at least one of stopLoss / takeProfit; send 0 to clear a level rather than move it.

{
  "ticket": 4072808150,
  "symbol": "BTCUSD",
  "side": "BUY",
  "volume": 0.10,
  "stopLoss": 72000,
  "takeProfit": 85000,
  "timestamp": "2026-05-22T18:12:09.000Z"
}

• ▸Requires an Idempotency-Key header.
• ▸You must supply at least one of stopLoss or takeProfit; sending neither is a VALIDATION_ERROR.
• ▸Some brokers enforce a minimum stop distance (stop level). Too-tight values come back as 422 BROKER_REJECTED. GET /v1/accounts/:id/symbol-specs reports that distance as stopLevel, in points, so you can check it before sending.
• ▸To CLEAR a protective level, send it as 0 — that removes it. 0 and "omitted" are different instructions: 0 means remove this level, omitting the field means leave it exactly as it is. So { "stopLoss": 0 } removes the stop-loss and keeps the take-profit untouched, and { "stopLoss": 0, "takeProfit": 0 } removes both. 0 also satisfies the at-least-one-field rule, so clearing is never an empty body.
• ▸The response and GET /v1/accounts/:id/positions both report a removed level as 0, not null — the same 0 you send. A position that never had an SL or TP reads 0 as well, so 0 consistently means "no level" in both directions.

Closed-trade history for the account — executed trades paired into round-trips (entry + exit), the equivalent of MT5’s history_deals_get. Returns the recent window your broker provides on connect plus any trades closed live during the session. Filter by symbol and close-time range.

{
  "trades": [
    {
      "ticket": "4072808150",
      "symbol": "ETHUSD",
      "side": "BUY",
      "volume": 0.10,
      "openPrice": 2500.50,
      "closePrice": 2510.25,
      "openTime": "2026-05-20T10:00:00.000Z",
      "closeTime": "2026-05-20T12:30:00.000Z",
      "brokerOpenTime": "2026-05-20T13:00:00+03:00",
      "brokerCloseTime": "2026-05-20T15:30:00+03:00",
      "profit": 0.98,
      "swap": -0.12,
      "commission": 0,
      "stopLoss": 0,
      "takeProfit": 0,
      "closeTicket": "4072808151",
      "complete": true
    }
  ],
  "count": 1,
  "limit": 500,
  "hasMore": false,
  "nextCursor": null,
  "serverTimeOffsetSeconds": 10800
}

• ▸openTime / closeTime are UTC. brokerOpenTime / brokerCloseTime are the same instants in the broker’s server-local time (RFC 3339 with offset), and serverTimeOffsetSeconds is that offset, measured from the broker’s own records. null means it could not be derived yet (no deal or open position on the account); 0 means a UTC server.
• ▸Returns what the broker provides for the account on connect plus trades closed live during the current session — how far back that reaches is set by the broker. An account connected with terminalType "CLIENT" (desktop terminal) reaches back roughly 11 days. from/to filter those rows; they do not fetch beyond what the broker provides.
• ▸MT4 accounts: the list is the account’s closed trades for the whole account, on the first read after the account connects; a trade that closes while it is connected is in the list from that moment. An account with no closed trades answers 200 with an empty list. After a reconnect the list is again the whole account.
• ▸MT4 accounts: coverage: "partial" appears when the list is not known to be the whole account, with coverageReason saying why — "history_still_loading" in the first moments of a connection while the history is still arriving (read again shortly: the list is then either complete, with no coverage key, or "history_load_failed"), "history_load_failed" when the history could not be read in (the list holds what was read, possibly nothing; reconnect the account — an account with more than 299,593 closed trades and balance entries is beyond what can be loaded and stays in this state), or "broker_session_window" when history loading for MT4 accounts has been limited to a recent window (the list covers that window). Both keys are absent otherwise. Each row is one whole closed trade (complete: true); pending orders that were cancelled are not here — GET /v1/accounts/:id/orders-history lists them together with the closed trades. Differences from MT5 rows: closeTicket is null (an MT4 trade has one ticket), profit is before swap and commission (net = profit + swap + commission), and there are no partial rows — on MT4 a partial close is its own closed trade and the remainder continues under a new ticket.
• ▸MT4 only, while the account’s serverTimeOffsetSeconds is null (the first few seconds after connect on some brokers, or a connection made while the market is closed): openTime and closeTime are null on every row — never the broker’s clock labelled as UTC — and brokerOpenTime / brokerCloseTime carry the broker’s wall-clock time with no offset suffix, e.g. "2026-11-12T18:06:12". The response adds timeBasis: "broker" and a timeBasisNote, and the rows are ordered, paged and from / to-filtered on that broker clock meanwhile — so a date-filtered or paged read made then can differ from the same read made later. Once the offset is known (0 counts as known) openTime and closeTime are UTC, the twins carry their numeric offset ("2026-11-12T18:06:12+02:00") and timeBasis is absent; read again then.
• ▸Each row is a round-trip: ticket is the open/position ticket; closeTicket is the closing deal. On a row not yet matched to its closing deal (complete: false) closeTicket is null or repeats ticket. profit is realised P/L in the account currency.
• ▸stopLoss / takeProfit are the position’s stop-loss and take-profit levels when it closed — the levels on its closing deal (closeTicket). 0 means no level was set. The levels the position was opened with are on its opening ("IN") deal in GET /v1/accounts/:id/deals-history.
• ▸A position closed in several partial closes is ONE row here, and it carries the levels of its last closing deal; each partial close’s own levels are on its "OUT" row in GET /v1/accounts/:id/deals-history. While part of the position is still open (a partial row), the levels are those of the latest partial close.
• ▸Right after connecting, until the account’s deal history has loaded, stopLoss / takeProfit can still show their earlier value (the opening order’s level, or 0). A read waits for that load by default (waitMs), so you only see it if you skip the wait or it runs out.
• ▸Open positions are never listed here — they live under GET /v1/accounts/:id/positions. complete=true is a confirmed round-trip with trustworthy P/L; complete=false marks a closed row we could not pair with its opening deal, where profit is reported as null rather than a misleading 0.
• ▸A partially closed position that still has volume open is listed as one row with partial: true: volume is the closed volume so far, remainingVolume is the volume still open, profit/swap/commission are the broker-booked figures for the closed part, and complete is false. When the rest closes, that row is replaced by a single row with the same ticket, the full volume, complete: true and no partial or remainingVolume fields.
• ▸swap is provided: the swap the broker booked on the position, in the account currency (non-zero for positions held across a rollover). commission is the commission the broker charged on the round-trip (opening plus closing deal), in the account currency, stored as the broker books it: negative for a charge, 0 on account types that charge none. A trade opened and closed within the current session shows its commission within about 30 seconds of the close (the ledger is re-read on the next history read after a balance change)
• ▸A cheap read that never disturbs your live tick stream. On a connection that has cooled you get 409 BROKER_ACCOUNT_NOT_HOT — POST /v1/sessions to reconnect.
• ▸MT5 accounts: if the envelope carries coverage: "partial", the list is not the account’s whole history. coverageReason says why: "history_still_loading" (the account’s history has not finished loading on this connection — read again shortly: the list is then either whole, or "history_load_failed"), "history_load_failed" (it could not be loaded on this connection, or the broker did not answer the request for it within 30 seconds; it loads again when the account reconnects), or "broker_session_window" (the account is connected with terminalType "CLIENT": such a connection is given only a recent window of the account’s history, so the list is complete for that window and not for the account — connect it as "MOBILE" for the whole history). When the list is whole, coverage and coverageReason are absent. The same two keys and values apply to /deals-history, /orders-history and /balance-operations.

Individual deal fills for the account — one row per executed deal, the equivalent of MT5’s "Deals" view (while /history is the aggregated one-row-per-position "Positions" view). Each entry — the open, and every PARTIAL and full close — is its own row with its own ticket, time, price and volume. Filter by symbol and time range.

{
  "deals": [
    {
      "ticket": "1952757330",
      "positionId": "2075644599",
      "symbol": "BTCUSDm",
      "side": "SELL",
      "entry": "OUT",
      "volume": 0.05,
      "price": 81390.12,
      "stopLoss": 81400,
      "takeProfit": 83000,
      "profit": -9.27,
      "swap": 0,
      "commission": -0.40,
      "time": "2026-10-18T14:21:10.000Z",
      "brokerTime": "2026-10-18T17:21:10+03:00"
    }
  ],
  "count": 1,
  "limit": 500,
  "hasMore": false,
  "nextCursor": null,
  "serverTimeOffsetSeconds": 10800
}

• ▸One row per DEAL (fill), not per position: a position opened and then closed in two parts is three rows — the open (entry "IN") and the two closing deals (entry "OUT"), each with its own ticket, time, price and volume. Use this when you need the individual exits; use GET /v1/accounts/:id/history for the aggregated one-row-per-position view (an MT5 terminal shows both the same way, as "Deals" and "Positions").
• ▸entry is the deal’s role: "IN" opened/added, "OUT" closed/reduced, "INOUT" a reversal, "OUT_BY" closed by an opposing position. positionId ties every deal to the position it belongs to; ticket is the deal’s own id.
• ▸stopLoss / takeProfit are the stop-loss and take-profit levels on the deal (MT5’s DEAL_SL / DEAL_TP). On an "IN" deal they are the levels the position was opened with; on an "OUT" deal they are the position’s levels when that deal closed it. So a stop that was moved shows its original value on the opening deal and the moved value on the closing deal. 0 means no level was set.
• ▸profit / swap / commission are the broker-booked realised figures on a CLOSE ("OUT") fill, in the account currency — so a partial exit shows its own exact realised P/L. They are ABSENT (not 0) on an "IN" / open fill, which books no P/L — treat absent as "not booked", never as 0.
• ▸time is UTC; brokerTime is the same instant in the broker’s server-local time (RFC 3339 with offset), and serverTimeOffsetSeconds is that offset — null if not derivable yet, 0 for a UTC server.
• ▸Trade fills only — deposits, withdrawals and other balance-ledger entries are NOT here; they live on GET /v1/accounts/:id/balance-operations.
• ▸MT5 only. MT4 keeps one record per closed trade, not one per fill, so an MT4 account answers 501 MT4_DEALS_HISTORY_UNAVAILABLE — use GET /v1/accounts/:id/history there.
• ▸Paged: while hasMore is true, call again with cursor=nextCursor (same filters) for the next older page; every row comes back exactly once, in order. nextCursor is null on the last page.
• ▸MT5 accounts: if the envelope carries coverage: "partial", the list is not the account’s whole history: retry shortly. coverageReason says why (the values are listed under GET /v1/accounts/:id/history).

Historical ORDERS for the account — one row per order that reached a final state (filled, cancelled, rejected, expired), the equivalent of MT5’s history orders. Distinct from /deals-history (the individual fills) and /history (the aggregated round-trips): this is the order-lifecycle view. On MT4 it lists each closed trade as one row plus the cancelled pending orders. Filter by symbol and time range.

{
  "orders": [
    {
      "orderTicket": "2075644598",
      "positionId": "2075644599",
      "symbol": "BTCUSDm",
      "side": "BUY",
      "volume": 0.10,
      "price": 81555.00,
      "state": "FILLED",
      "fillingType": null,
      "dealCount": 1,
      "time": "2026-10-18T14:20:02.000Z",
      "brokerTime": "2026-10-18T17:20:02+03:00"
    },
    {
      "orderTicket": "2075601177",
      "positionId": "0",
      "symbol": "BTCUSDm",
      "side": "BUY",
      "volume": 0.10,
      "price": 79000.00,
      "state": "CANCELED",
      "fillingType": "RETURN",
      "dealCount": 0,
      "time": "2026-10-09T08:02:41.000Z",
      "brokerTime": "2026-10-09T11:02:41+03:00"
    }
  ],
  "count": 2,
  "limit": 500,
  "hasMore": false,
  "nextCursor": null,
  "serverTimeOffsetSeconds": 10800
}

• ▸One row per ORDER. orderTicket is the order’s own ticket (distinct from the position ticket); positionId links it to the position it opened or acted on. volume is the order’s volume and price its request / fill price.
• ▸On an account connected with the default terminalType ("MOBILE"), the first read after connecting returns the account’s full order history, back to its first order, including cancelled, rejected and expired orders. An account connected with terminalType "CLIENT" (desktop terminal) lists roughly the last 11 days. from / to narrow the list; without them you page through all of it, newest first.
• ▸state is how the order ended: "FILLED", "CANCELED", "REJECTED", "EXPIRED" or "PARTIAL". Each is the broker’s own verdict: a rejected order is "REJECTED" and an expired one "EXPIRED", never "CANCELED". "PARTIAL" is an order that filled in part and whose record still says so; it always has dealCount above 0. An order that filled in part and was then cancelled or expired reads "CANCELED" / "EXPIRED" with its fills (volume is the filled volume, dealCount above 0). "UNKNOWN" is reserved for an order whose state could not be read; treat it as not filled.
• ▸An order that never filled has positionId "0" and dealCount 0. dealCount is how many deal fills the order produced (a market order is normally 1).
• ▸fillingType is the order’s filling type, by MT5’s names: "FOK", "IOC", "RETURN" or "BOC". It is a separate fact from state — an order placed with "RETURN" can end filled, cancelled, rejected or expired. It is set on cancelled, rejected and expired orders and null on orders that have fills.
• ▸time is UTC; brokerTime is the same instant in the broker’s server-local time (RFC 3339 with offset), and serverTimeOffsetSeconds is that offset — null if not derivable yet, 0 for a UTC server.
• ▸For the individual fills an order produced, use GET /v1/accounts/:id/deals-history (join on positionId); for the aggregated round-trip with realised P/L, GET /v1/accounts/:id/history. Trade orders only — no balance-ledger entries.
• ▸MT4 accounts: the list holds each closed trade as ONE row and each pending order that left the book without filling. An MT4 trade is one record from open to close, so its row is state "FILLED" with orderTicket = the trade’s ticket (positionId is the same ticket, and so is ticket on /history), type "BUY" or "SELL", price = the open price, and the close on the same row: closePrice, closeTime, profit, swap and commission, plus openTime, stopLoss, takeProfit, comment and magic as on /history. A pending order that left the book without filling is state "CANCELED" — on MT4 the state is only ever "FILLED" or "CANCELED": a pending order that expired also reads "CANCELED", because MT4 does not tell an expiry from a cancel (its expirationTime is on the row). A pending order that triggers is not a cancelled row: it becomes a position, and once that position closes it is one "FILLED" row. A cancelled row has type "BUY_LIMIT", "SELL_LIMIT", "BUY_STOP" or "SELL_STOP", price = the order’s price, with setTime (when it was placed), expirationTime (null = none), stopLoss, takeProfit, comment and magic; it never filled, so positionId is "0" and dealCount 0. time is when the row became history — the trade’s close, the order’s removal — and it is what from / to and the newest-first order use. fillingType is null on MT4 rows, and dealCount is null on a closed trade (MT4 has no deal records). Every time field has a broker-clock twin (brokerTime, brokerOpenTime, brokerCloseTime, brokerSetTime, brokerExpirationTime). Open positions and resting pending orders are not history and are not listed (GET /positions, GET /orders). On MT4 this list is more complete than /history, which lists closed trades only; /deals-history is not available on MT4.
• ▸MT4 accounts: coverage / coverageReason, serverTimeOffsetSeconds and timeBasis behave exactly as on GET /v1/accounts/:id/history. While serverTimeOffsetSeconds is null, every UTC time a row has (time, openTime, closeTime, setTime, expirationTime) is null and its broker* twin carries the broker’s wall-clock time with no offset suffix, e.g. "2026-11-12T18:06:12"; once it is known the UTC fields are filled and the twins carry their numeric offset. A cancel is in the list on the first read after it, and the list is the same after a reconnect. An MT4 account whose connection cannot list its cancelled pending orders answers 501 MT4_ORDERS_HISTORY_UNAVAILABLE instead of an incomplete list.
• ▸Paged: while hasMore is true, call again with cursor=nextCursor (same filters) for the next older page; every row comes back exactly once, in order. nextCursor is null on the last page.
• ▸MT5 accounts: if the envelope carries coverage: "partial", the list is not the account’s whole history: retry shortly. coverageReason says why (the values are listed under GET /v1/accounts/:id/history).

Balance operations for the account — money moving in or out (deposits, withdrawals, credits, charges, corrections, bonuses), kept separate from trades so a deposit is never summed as P/L. The equivalent of MT5’s DEAL_TYPE_BALANCE family. Newest-first, like every history route — reverse it to fold into an equity curve.

{
  "operations": [
    {
      "ticket": "4138294581",
      "type": "deposit",
      "dealType": 2,
      "amount": 500,
      "profit": 500,
      "symbol": null,
      "positionId": null,
      "time": "2026-09-12T15:44:08.000Z",
      "brokerTime": "2026-09-12T18:44:08+03:00",
      "account": 434221754,
      "comment": "Deposit"
    }
  ],
  "count": 1,
  "limit": 500,
  "hasMore": false,
  "nextCursor": null,
  "serverTimeOffsetSeconds": 10800,
  "windowed": true
}

• ▸type is one of deposit, withdrawal, credit, charge, correction, bonus, commission, other. deposit / withdrawal are derived from the sign of amount; the rest map the broker’s own ledger kinds. dealType is the broker’s raw ENUM_DEAL_TYPE, passed through so an unrecognised kind is never silently flattened.
• ▸amount is signed and in the account currency, exactly as the broker booked it: positive = money in, negative = money out.
• ▸From v1.41.0 every row also carries comment, profit, symbol and positionId; an account on a dedicated environment gets them once that environment is updated. comment is the broker’s own text for the entry (for example "Deposit" or "DV p=1234567890, XOP.NYSE"); null when the broker wrote none. profit is the amount as the broker booked it and is always equal to amount; 0 is a real value.
• ▸symbol and positionId are filled only when the broker’s entry carries them, and brokers generally do not: a dividend or adjustment tied to a position usually names the position and instrument only in comment, so expect null on both. positionId is a string (ids can exceed 2^53) and is null, never "0", when the entry belongs to no position. Both are always null on an MT4 account.
• ▸Paged: while hasMore is true, call again with cursor=nextCursor (same filters) for the next older page; every row comes back exactly once, in order. nextCursor is null on the last page.
• ▸time is UTC; brokerTime is the same instant in the broker’s server-local time (RFC 3339 with offset), and serverTimeOffsetSeconds is that offset. null means it could not be derived yet (no deal or open position on the account); 0 means a UTC server.
• ▸MT4 accounts: the list is the account’s deposits, withdrawals and broker credit for the whole account, on the first read after the account connects; an entry booked while it is connected is in the list from that moment. An account with none answers 200 with an empty list.
• ▸MT4 accounts: coverage: "partial" appears when the list is not known to be the whole account, with the same coverageReason values as GET /v1/accounts/:id/history ("history_still_loading", "history_load_failed", "broker_session_window"); both keys are absent otherwise. type is "deposit" or "withdrawal" by the sign of amount, or "credit" for a broker credit; dealType is null.
• ▸MT4 only, while the account’s serverTimeOffsetSeconds is null (the first few seconds after connect on some brokers, or a connection made while the market is closed): time is null on every row — never the broker’s clock labelled as UTC — and brokerTime carries the broker’s wall-clock time with no offset suffix, e.g. "2026-11-12T18:06:12". The response adds timeBasis: "broker" and a timeBasisNote, and the rows are ordered, paged and from / to-filtered on that broker clock meanwhile — so a date-filtered or paged read made then can differ from the same read made later. Once the offset is known (0 counts as known) time is UTC, brokerTime carries its numeric offset ("2026-11-12T18:06:12+02:00") and timeBasis is absent; read again then.
• ▸Returns what the broker provides for the account on connect — the same rule as /history. An empty list means no operations in what the broker provided, not that the account was never funded; treat the oldest row as a floor, not the account’s opening.
• ▸No symbol filter: balance operations are account-level. Realtime: the WebSocket account channel pushes an account_update on every balance change, including deposits and withdrawals — read this endpoint on that push to learn what moved the balance. A new operation is refreshed from the broker on the first read after the balance moved, so it is readable within seconds of the push.
• ▸A cheap read that never disturbs your live tick stream. On a connection that has cooled you get 409 BROKER_ACCOUNT_NOT_HOT — POST /v1/sessions to reconnect.
• ▸MT5 accounts: if the envelope carries coverage: "partial", the list is not the account’s whole history: retry shortly. coverageReason says why (the values are listed under GET /v1/accounts/:id/history).

Place orders across many of your accounts in one request — one call fans out to every account you name, and each order’s outcome is reported separately. An account can appear more than once, so one call can send several legs to the same account. Requires a Pro or Enterprise plan.

{
  "results": [
    { "accountId": "acc_8Kd3...", "status": "filled", "ticket": 4072808150, "price": 77512.73, "symbol": "BTCUSD" },
    { "accountId": "acc_9Lm4...", "status": "failed", "symbol": "BTCUSD", "code": "BROKER_REJECTED", "reason": "Not enough money" }
  ],
  "summary": { "total": 2, "filled": 1, "failed": 1 }
}

• ▸Requires a Pro or Enterprise plan — on the Free and Trader plans this call returns 403.
• ▸Requires an Idempotency-Key header (see Conventions). Re-sending the same key replays the original response without placing any order a second time.
• ▸Partial success — a mix of filled and failed accounts still returns 200. Read each account’s outcome in results: status is "filled" (with its ticket and fill price) or "failed" (with a code and human-readable reason). summary tallies total / filled / failed.
• ▸Works on both live and demo accounts — there is no account-type restriction beyond the Pro / Enterprise plan requirement above.
• ▸Several legs on one account — repeat its accountId. results come back in the order you sent them. On one account, market orders run in parallel and pending orders are placed one after another.

Close positions across many accounts in one request — either an explicit list of positions, or a per-account intent that flattens each account (optionally narrowed by its own broker-native symbol or side). Requires a Pro or Enterprise plan.

{
  "results": [
    { "accountId": "acc_8Kd3...", "ticket": 4072808150, "status": "ok", "symbol": "BTCUSD", "side": "BUY", "volume": 0.10, "closed": true, "closePrice": 81320.15, "dealTicket": "1191098644", "profit": -0.40, "swap": 0, "commission": 0 },
    { "accountId": "acc_9Lm4...", "ticket": 4072809002, "status": "failed", "symbol": "BTCUSD", "side": "SELL", "volume": 0.20, "closed": false, "code": "TICKET_NOT_FOUND", "reason": "Position not open" }
  ],
  "summary": { "total": 2, "ok": 1, "failed": 1 }
}

• ▸Requires a Pro or Enterprise plan — on the Free and Trader plans this call returns 403.
• ▸Requires an Idempotency-Key header. Re-sending the same key replays the original response without closing anything twice; re-using it with a different body is a 409 IDEMPOTENCY_KEY_REUSED.
• ▸Each "ok" result carries the booked closing deal (closePrice, dealTicket, profit, swap, commission), null when not yet booked.
• ▸Two modes: pass items for an explicit per-position list, OR targets for a per-account intent (each { accountId, symbol?, side? }, with its own broker-native symbol). Supplying neither is a 400.
• ▸Partial success — each position’s outcome is in results: status "ok" (closed true) or "failed" (with a code and reason). summary tallies total / ok / failed.
• ▸Each "ok" result carries the booked close deal (closePrice, dealTicket, profit, swap, commission), as on the single close; null until the broker books it.

Modify the stop-loss and/or take-profit on positions across many accounts in one request. Requires a Pro or Enterprise plan.

{
  "results": [
    { "accountId": "acc_8Kd3...", "ticket": 4072808150, "status": "ok", "symbol": "BTCUSD", "side": "BUY", "modified": true },
    { "accountId": "acc_9Lm4...", "ticket": 4072809002, "status": "failed", "symbol": "BTCUSD", "side": "SELL", "modified": false, "code": "BROKER_REJECTED", "reason": "Invalid stops" }
  ],
  "summary": { "total": 2, "ok": 1, "failed": 1 }
}

• ▸Requires a Pro or Enterprise plan — on the Free and Trader plans this call returns 403.
• ▸Requires an Idempotency-Key header.
• ▸Each item must carry at least one of stopLoss / takeProfit; an omitted field is preserved at its current value, and a field sent as 0 REMOVES that level — the same meaning as on the single-account PATCH this fans out to. So { accountId, ticket, stopLoss: 0 } clears the stop on that position and leaves its take-profit alone.
• ▸Partial success — per-position outcome in results: status "ok" (modified true) or "failed" (with a code and reason). summary tallies total / ok / failed.

Cancel resting pending orders (LIMIT / STOP) across many accounts in one request — an explicit list, or a per-account intent that cancels the pending orders on each account (optionally narrowed by its own broker-native symbol). Requires a Pro or Enterprise plan.

{
  "results": [
    { "accountId": "acc_8Kd3...", "ticket": 4072809988, "status": "ok", "cancelled": true },
    { "accountId": "acc_9Lm4...", "ticket": 4072809991, "status": "failed", "cancelled": false, "code": "TICKET_NOT_FOUND", "reason": "Not a resting pending order" }
  ],
  "summary": { "total": 2, "ok": 1, "failed": 1 }
}

• ▸Requires a Pro or Enterprise plan — on the Free and Trader plans this call returns 403.
• ▸Requires an Idempotency-Key header.
• ▸Two modes: items for an explicit list, OR targets for a per-account intent (each { accountId, symbol? }, with its own broker-native symbol). Supplying neither is a 400.
• ▸Partial success — per-order outcome in results: status "ok" (cancelled true) or "failed" (with a code and reason). summary tallies total / ok / failed.
• ▸Works on MT4 and MT5 accounts.

Modify resting pending orders (trigger price, stop-loss, take-profit) across many accounts in one request. Requires a Pro or Enterprise plan.

{
  "results": [
    { "accountId": "acc_8Kd3...", "ticket": 4072809988, "status": "ok", "modified": true },
    { "accountId": "acc_9Lm4...", "ticket": 4072809991, "status": "failed", "modified": false, "code": "TICKET_NOT_FOUND", "reason": "Not a resting pending order" }
  ],
  "summary": { "total": 2, "ok": 1, "failed": 1 }
}

• ▸Requires a Pro or Enterprise plan — on the Free and Trader plans this call returns 403.
• ▸Requires an Idempotency-Key header.
• ▸Each item must carry at least one of price / stopLoss / takeProfit; an omitted field is preserved at its current value, and stopLoss or takeProfit sent as 0 REMOVES that level. price is the exception — it must be positive, since a resting order needs a trigger.
• ▸Partial success — per-order outcome in results: status "ok" (modified true) or "failed" (with a code and reason). summary tallies total / ok / failed.

Read live state for many accounts in one request — connection status, margin mode, read-only flag, account financials and open positions for your whole roster (or a subset) in a single call. Each account comes back as the same object GET /v1/accounts/:id returns. Requires a Pro or Enterprise plan.

{
  "accounts": [
    {
      "id": "acc_8Kd3...",
      "broker": "mt5",
      "server": "Exness-MT5Trial14",
      "accountNumber": "****5678",
      "externalRef": null,
      "isDemo": true,
      "group": "demo\\Standard",
      "serverTimeOffsetSeconds": 0,
      "hot": true,
      "poolId": "pool_3",
      "ownerApiKeyId": null,
      "readOnly": false,
      "marginMode": "hedging",
      "terminalType": "MOBILE",
      "alwaysHot": false,
      "credentialRejectedAt": null,
      "lastHotAt": "2026-08-29T09:30:01.000Z",
      "createdAt": "2026-08-20T09:11:55.000Z",
      "status": "online",
      "account": { "group": "demo\\Standard", "balance": 9871.42, "currency": "USD", "equity": 9863.10, "margin": 142.50, "freeMargin": 9720.60, "marginLevel": 6921.5, "credit": null, "leverage": 500, "serverTimeOffsetSeconds": 0 },
      "positions": [
        { "ticket": 4072808150, "symbol": "BTCUSD", "side": "BUY", "volume": 0.10, "entryPrice": 77512.73, "currentPrice": 77640.10, "profit": 12.74, "openTime": "2026-08-29T09:41:10.000Z", "brokerOpenTime": "2026-08-29T09:41:10+00:00" }
      ]
    },
    {
      "id": "acc_9Lm4...",
      "broker": "mt5",
      "server": "ICMarketsSC-Demo",
      "accountNumber": "****3311",
      "externalRef": null,
      "isDemo": true,
      "group": "demo\\Raw",
      "serverTimeOffsetSeconds": 7200,
      "hot": false,
      "poolId": null,
      "ownerApiKeyId": null,
      "readOnly": null,
      "marginMode": null,
      "terminalType": "WEB",
      "alwaysHot": false,
      "credentialRejectedAt": "2026-08-29T08:05:44.000Z",
      "lastHotAt": "2026-08-28T21:15:09.000Z",
      "createdAt": "2026-08-21T14:02:10.000Z",
      "status": "offline"
    }
  ],
  "notFound": [],
  "summary": { "total": 2, "online": 1, "offline": 1 }
}

• ▸Requires a Pro or Enterprise plan — on the Free and Trader plans this call returns 403.
• ▸Not idempotent and takes no body — pass ids and include as query-string parameters.
• ▸One round-trip for your whole roster. Each element of accounts is the object GET /v1/accounts/:id would return for that account at that moment — the same fields, values and null rules — so you never need a per-account call to learn an account’s connection status, margin mode or read-only flag. include only removes the account and/or positions blocks.
• ▸status is the live connection status, with the same two values as on GET /v1/accounts/:id. "online": the account is connected and its live figures were read (its account and positions blocks are present, per include). "offline": the account is not connected (hot is false — POST /v1/sessions to reconnect), or it is connected but its live figures could not be read for this one response (hot is true — read again); the account/positions blocks are omitted. It is not the registration status that GET /v1/accounts lists ("CONNECTED" / "PENDING").
• ▸marginMode is the account’s margin model: "netting" (one aggregate position per symbol), "hedging" (independent positions per symbol) or "exchange". null means it is not known right now — the account is not connected, it connected only a few seconds ago, or it is an MT4 account.
• ▸readOnly is true when the broker reports the login as read-only (an investor password): reads work, and an order, close, modify or cancel answers 409 BROKER_READ_ONLY. false means full trading rights. null means not known — the account is not connected or connected only a few seconds ago; on MT4 it is true or null, and null there means "not known to be read-only".
• ▸credentialRejectedAt is null when nothing is wrong. A timestamp means the broker refused the account’s remembered password at that time: the row stays "offline" until one POST /v1/sessions with the current password, which sets the field back to null.
• ▸serverTimeOffsetSeconds is the broker’s server-local offset from UTC in seconds, as last measured on the account: 0 means a UTC server, null means not measured yet. group is the broker’s own account group, null only for an account that has never connected. Both are kept between connections, so an offline row still carries them.
• ▸ownerApiKeyId is the isolated API key the account belongs to; null means the shared pool. lastHotAt is when the account last became connected, null if it has not connected yet.
• ▸include controls the per-account payload: "account" adds the financials block, "positions" adds open positions; both are included by default. Drop one to make the response smaller.
• ▸Any ids you pass that are not on your key — or that belong to an account that was removed or refused — come back in notFound. summary tallies total / online / offline.

Create a copy set — one master account whose trades are mirrored to your follower accounts, each scaled and risk-clamped to its own size. All accounts are your own. Requires a Pro or Enterprise plan.

{
  "id": "cset_7Hb2...",
  "ownerId": "usr_9Kd3...",
  "name": "My desk",
  "masterAccountId": "acc_master",
  "enabled": false,
  "failurePolicy": "retry",
  "webhookUrl": null,
  "hasWebhookSecret": false,
  "createdAt": "2026-08-29T12:00:00.000Z",
  "updatedAt": "2026-08-29T12:00:00.000Z",
  "followers": [
    { "id": "cf_1", "followerAccountId": "acc_1", "sizingMethod": "proportional", "reverse": false, "enabled": true }
  ]
}

• ▸Requires a Pro or Enterprise plan — on the Free and Trader plans this call returns 403 (COPY_REQUIRES_PRO).
• ▸Self-copy only — the master and every follower must be your own accounts. A follower cannot also be the master.
• ▸A new set is created paused (enabled false). Arm it with PATCH /v1/copy/sets/:setId { "enabled": true } once you’re happy with the followers.
• ▸While live copying is being rolled out, mirrored trades run on demo followers; managing sets and reading stats works on all accounts.

List your copy sets, each with a follower count. Requires a Pro or Enterprise plan.

{
  "sets": [
    { "id": "cset_7Hb2...", "name": "My desk", "masterAccountId": "acc_master", "enabled": true, "failurePolicy": "retry", "_count": { "followers": 3 }, "createdAt": "2026-08-29T12:00:00.000Z", "updatedAt": "2026-08-29T12:00:00.000Z" }
  ]
}

• ▸Requires a Pro or Enterprise plan.

Get one copy set with its full follower list + config. Requires a Pro or Enterprise plan.

{
  "id": "cset_7Hb2...",
  "name": "My desk",
  "masterAccountId": "acc_master",
  "enabled": true,
  "failurePolicy": "retry",
  "followers": [
    { "id": "cf_1", "followerAccountId": "acc_1", "sizingMethod": "multiplier", "sizingValue": 0.5, "maxLot": 1, "reverse": false, "enabled": true }
  ]
}

• ▸Requires a Pro or Enterprise plan.
• ▸Returns 404 if the set is not yours.

Update a set — rename, change the failure policy, or arm / pause it. Requires a Pro or Enterprise plan.

{ "id": "cset_7Hb2...", "name": "My desk", "enabled": true, "failurePolicy": "retry", "followers": [ ... ] }

• ▸Requires a Pro or Enterprise plan.
• ▸Provide at least one field. Arming is just enabled: true.

Delete a copy set (and its followers, position map, and log). Requires a Pro or Enterprise plan.

204 No Content — empty body.

• ▸Requires a Pro or Enterprise plan.
• ▸Open follower positions are NOT closed — deleting a set only stops future mirroring.

Add a follower to a set. Requires a Pro or Enterprise plan.

{ "id": "cf_4", "copySetId": "cset_7Hb2...", "followerAccountId": "acc_4", "sizingMethod": "proportional", "reverse": true, "maxSlippagePips": 3, "enabled": true }

• ▸Requires a Pro or Enterprise plan.
• ▸The follower must be your own account, not the master, and not already in the set.

Update a follower’s config — only the fields you send change. Requires a Pro or Enterprise plan.

{ "id": "cf_4", "copySetId": "cset_7Hb2...", "followerAccountId": "acc_4", "sizingMethod": "fixed", "sizingValue": 0.02, "maxLot": 1 }

• ▸Requires a Pro or Enterprise plan.

Remove a follower from a set. Requires a Pro or Enterprise plan.

204 No Content — empty body.

• ▸Requires a Pro or Enterprise plan.
• ▸Open positions the follower already holds are NOT closed.

Dashboard stats for a set — totals, replication rate, and per-follower rollups. Requires a Pro or Enterprise plan.

{
  "set": { "id": "cset_7Hb2...", "name": "My desk", "enabled": true, "masterAccountId": "acc_master", "failurePolicy": "retry", "followerCount": 3 },
  "totals": { "ok": 128, "skipped": 4, "failed": 2, "replicationRate": 0.9846 },
  "byAction": { "open": 66, "close": 60, "modify": 8 },
  "followers": [
    { "followerAccountId": "acc_1", "enabled": true, "sizingMethod": "proportional", "ok": 44, "skipped": 1, "failed": 0, "openPositions": 2, "avgLatencyMs": 138 }
  ]
}

• ▸Requires a Pro or Enterprise plan.
• ▸Derived from the copy log: totals tally ok / skipped / failed; replicationRate is ok ÷ (ok + failed). Per follower: outcome counts, current open copied positions, and average fill latency.

The copy log for a set — every mirrored action and its outcome, newest first. Requires a Pro or Enterprise plan.

{
  "entries": [
    { "id": "clg_9", "followerAccountId": "acc_1", "action": "open", "masterTicket": "4072808150", "followerTicket": "5510022931", "symbol": "EURUSDm", "mappedSymbol": "EURUSD", "volume": 0.01, "result": "ok", "latencyMs": 132, "createdAt": "2026-08-29T12:34:56.000Z" },
    { "id": "clg_8", "followerAccountId": "acc_2", "action": "open", "symbol": "XAUUSDm", "volume": null, "result": "skipped", "reason": "XAUUSD is on the block list", "createdAt": "2026-08-29T12:34:56.000Z" }
  ],
  "nextBefore": "2026-08-29T12:34:56.000Z"
}

• ▸Requires a Pro or Enterprise plan.
• ▸Newest first. limit and before are query-string parameters; page by passing the previous response’s nextBefore back as before (null means the end).
• ▸result is "ok", "skipped" (with a reason — e.g. filtered by a rule), or "failed" (with a reason). action is open / close / partial_close / modify / pending_place / pending_cancel / pending_modify.