Reaching the trade history and live feed behind an IQ Option account

An IQ Option account holds a running record most traders never export: every closed deal with its execution price, the open positions in the portfolio, the real and the practice balance side by side, and the candle stream the traderoom draws its charts from. All of it moves over a single persistent websocket session once the app authenticates. That session is the thing worth integrating, and reaching it under the account holder's own authorization is routine work for us.

The platform runs as a layered operation. EEA clients are served by IQOPTION EUROPE LTD under Cyprus (CySEC) oversight; clients elsewhere — the audience this Bengali-localized build mostly serves — are served by SKY LADDER LLC, registered in Antigua and Barbuda, as the company's own materials state. That split changes which rules sit behind an account, but not the data the account carries or how we reach it.

Bottom line: one authenticated session exposes balances, the live portfolio, closed-deal history and quote candles together, which is unusual and convenient. The route we'd actually take is to drive that session against a consenting account and normalize what comes off it — described below.

Data surfaces an IQ Option account exposes

Rows reflect surfaces the platform's own help materials describe — the Trading History list with per-deal execution detail, and the portfolio view for live positions. The candle subscription is the busiest of these; everything else is request-and-reply over the same socket.

On the wire

The traderoom speaks JSON over a websocket. Authentication is a session token (the platform calls it the ssid) carried in the first frame; subsequent frames are named commands with a request id. The sketch below mirrors the message shapes community libraries have documented for the public endpoint — exact field names and the active_id mapping get pinned down against a live session during the build, since they drift.

// Illustrative — message shapes confirmed against a consenting session at build time
ws = connect("wss://iqoption.com/echo/websocket")

// 1. authenticate with the existing session token
send({ name: "ssid", msg: "<account-session-token>" })

// 2. read both balances (real + practice come back tagged)
send({ name: "get-balances", request_id: "bal-1", msg: {} })
// -> [{ id, type: "real", amount, currency }, { type: "practice", amount }]

// 3. closed deals, paged
send({ name: "get-positions-history",
       request_id: "hist-1",
       msg: { instrument_types: ["digital-option","forex"], limit: 100 } })
// -> { positions: [{ id, instrument, open_price, close_price, pnl, close_at }] }

// 4. subscribe to live candles for one asset
send({ name: "subscribe-message",
       msg: { name: "candle-generated", params: { active_id: 76, size: 1 } } })
// stream -> { open, close, min, max, bid, ask, volume, at }

onError(frame => retryWithBackoff(frame.request_id))  // sessions expire; reconnect + re-auth

Two things shape the implementation: the socket can drop and the token expires, so reconnection and re-auth are not optional; and history is paged, so a backfill pass walks it rather than assuming one response holds everything.

What you get back

Each engagement ends with runnable code and the documents to operate it, scoped to the surfaces above:

• An OpenAPI/auth-flow spec that maps the websocket commands to a clean REST shape your systems can call — balances, positions, history, candle subscriptions.
• A protocol and session report: how the ssid is obtained and refreshed, the command/response frames, the active_id mapping for the assets you care about, and the error and reconnect behaviour.
• Runnable source for the key reads in Python or Node.js — connect, authenticate, page the history, stream candles, normalize the output.
• Automated tests covering auth, a history backfill, and a live candle subscription, plus the re-validation checks that catch protocol drift.
• Interface documentation and data-retention guidance covering what is stored, for how long, and how consent is recorded.

Routes to the data

1. Consented interface integration / protocol analysis

We analyze the traderoom traffic against an account the holder has authorized us to use, then implement the reads as a stable service. This reaches balances, live positions, closed-deal history and candle streams in one session. Effort is moderate; durability depends on the platform front end, which we account for with a re-validation pass. Access to a working account is arranged with you during onboarding.

2. User-consented session access

Where the account holder prefers to keep their own credentials, the integration drives their consented session rather than holding long-lived secrets — useful when the data is being pulled on behalf of the account's owner.

3. Native Trading History export (fallback)

The Trading History view shows closed deals with execution detail and can be read directly. It is the most stable surface but the narrowest — no live positions, no candle stream — so it suits a one-off ledger pull more than an ongoing sync.

For most requests we'd build on route 1: it is the only path that returns the live portfolio and the closed-deal ledger from the same authenticated session, which is exactly what a trading dashboard or a reporting pipeline needs. Route 3 is worth folding in as the dependable backstop for historical deals when the socket is unavailable.

Consent and oversight

Binary-options and CFD brokers sit outside account-aggregation schemes like AIS, so there is no open-banking consent rail here to ride. The basis we build on is the account holder's own authorization, recorded and scoped to the surfaces in the table. For EEA accounts under IQOPTION EUROPE LTD, the CySEC-regulated entity, personal data handling falls under GDPR; for accounts under SKY LADDER LLC in Antigua and Barbuda, the FSRC framework and the platform's own terms govern. We work authorized, log access, minimize what we pull to the fields you asked for, and sign an NDA where the data is sensitive. Consent is revocable, and the integration is built so revoking it stops the data flow cleanly.

Engineering notes specific to this platform

Two things we design around from the start:

• Session lifetime and reconnection. The ssid expires and the socket drops; we build the reader to detect that, re-authenticate, and resume the candle subscriptions and any in-flight history paging without losing or duplicating rows.
• Asset identifiers drift. Instruments are addressed by numeric active_id rather than ticker, and that mapping changes on the platform side. We snapshot the mapping during the build and wire a check that flags when an id stops resolving, so a renamed or delisted asset surfaces as an alert instead of a silent gap.
• Real versus practice separation. Because the demo account mirrors the live one closely, we tag every balance, position and deal with its account type so reporting never mixes practice activity into real performance.

Working with us

Delivery on an IQ Option integration runs about one to two weeks once we have a consenting account to build against. From there you choose how to pay. Source-code delivery starts at $300: you get the runnable source, the spec, the tests and the documentation, and you pay after delivery once the integration works to your satisfaction. Or run it as a pay-per-call hosted API — you call our endpoints for balances, history, positions and candles and pay only for the calls you make, with no upfront fee. Tell us the app and what you want out of it and we'll point you at the right one. Start the conversation here.

Freshness and reliability

Balances and open positions are real-time off the socket; closed-deal history is as current as the platform's records and pages back through prior deals. The candle stream delivers per-interval ticks live, which is why the reconnect handling matters — a dropped socket means missed candles unless it resumes. We size polling and subscription concurrency to what your use case needs rather than opening every channel by default.

Interface evidence

Store screenshots of the traderoom and dashboard the integration reads from:

Similar platforms in the same integration space

Teams pulling broker data rarely stop at one platform, so it helps to see where IQ Option sits. Each of these holds comparable per-account records — balances, deal history, positions — and a unified integration normalizes them to one schema:

• Quotex — fixed-time options platform with per-account trade history and balances behind a login.
• Pocket Option — options broker with copy-trading data and per-user deal logs.
• Olymp Trade — fixed-time and forex platform with multi-asset history and account balances.
• Binomo — options platform with tournament and trade records per account.
• Expert Option — options broker exposing positions and withdrawal/deal history per user.
• IQcent — options and forex broker with account-level trade and balance records.
• Deriv — multi-asset broker with a documented trading API and per-account statements.
• MetaTrader 5 — terminal used by many brokers, with order, deal and position history per account.

Questions integrators ask about IQ Option

Can you reach both my real and my practice account balances?

Yes. The platform's profile and balance channel separates the funded (real) balance from the reloadable practice balance, so the integration can read either one and tell them apart rather than collapsing them into a single figure.

Is per-deal detail like execution price available, or only open positions?

Both. Open positions come from the live portfolio stream, and the Trading History surface carries closed deals with execution price, open and close, and realized profit or loss per deal — which is what makes a usable ledger sync.

The traderoom protocol is undocumented and shifts. How do you keep an IQ Option integration working?

We treat protocol drift as part of the job, not an exception. The build ships with a re-validation step and field-level checks so that when message shapes or active_id mappings change on the platform side, the break is caught and patched rather than silently returning stale numbers.

Which IQ Option entity and regulator applies to my account?

It depends where the account sits. EEA accounts are served by IQOPTION EUROPE LTD under CySEC oversight; accounts outside the EEA are served by SKY LADDER LLC, registered in Antigua and Barbuda under the FSRC, as the platform's own materials describe. Either way the dependable basis we build on is the account holder's own authorization.

App profile

How this was checked

We reviewed the platform's own help and blog material on verifying trades and the Trading History and Profile surfaces, alongside community documentation of the public websocket session, balance and candle channels, and the operator/regulatory structure. Primary sources opened:

• IQ Option blog — verifying trades and Trading History
• Community docs — profile/balance and candle websocket objects
• WikiFX — IQ Option regulation and operating entities
• FXScouts — CySEC licence and Sky Ladder LLC structure

Mapped by the OpenBanking Studio integration desk, June 2026.