Integrating QST Mobile quote streams, orders, and account state

Two clocks run inside QST Mobile, and an integration has to respect both. Real-time streaming quotes on gold, crude, the grains, treasuries and the equity boards refresh tick by tick; the account side — working orders, fills, open positions, price alarms — changes only when the trader or the market moves it. Most of the engineering on this app is keeping those two cadences in one coherent store. The route we use is authorized protocol analysis of the app's traffic plus a delta-synced client, run under the account holder's own consent.

Bottom line: the valuable, third-party-relevant data here is per-account — what a trader is holding, what they have working, and what filled — sitting alongside a high-rate quote feed. We map both surfaces, normalize them into one schema, and hand over a client that keeps the account side reconciled against the stream. Symbol handling and exchange entitlements are where the real work sits, not in the transport itself.

What sits behind a QST login

Each row below is something the app surfaces to its own user. The integration reads the same records through an authorized session, then normalizes them.

A client sketch for the two cadences

The shape below is illustrative. Field names get confirmed against the observed session during the build, not copied from a fixed contract. It shows the split that matters: quotes stream, account activity is delta-polled against a cursor.

# Normalized client we hand over. Names verified during the build,
# not asserted from any published contract.

from qst_client import Session     # the client produced for your repo

s = Session(token=consent_token)   # short-lived, user-consented session

# 1) Quotes and depth stream over the Protocol-Buffers websocket the app uses
s.subscribe(
    symbols=["GCQ6", "CLQ6", "ESU6"],   # futures carry a contract-month suffix
    depth=10,
    on_tick=lambda q: book.upsert(q.symbol, bid=q.bid, ask=q.ask, last=q.last),
)

# 2) Orders, fills and positions are NOT pushed the same way: read a delta page
cursor = store.last_cursor() or "0"
while running:
    page = s.activity(since=cursor, limit=200)   # orders, fills, positions
    for ev in page.events:
        store.apply(ev)          # keyed on (ev.account, ev.order_id, ev.seq),
                                 # so a re-poll over the same window is a no-op
    cursor = page.next_cursor
    if not page.has_more:
        sleep(2)                 # the stream stays hot; activity is delta-polled

A websocket gap and a missed poll are handled as separate failures — the quote book rebuilds from a fresh snapshot, while the activity reader just resumes from its last good cursor.

What lands in your repo

The headline deliverable is code that runs against this app's surfaces, not a binder of diagrams.

• A runnable client in Python or Node.js: the quote/depth subscription plus the cursor-paged activity reader, wired to the normalized schema.
• A websocket handler for the streaming feed, with reconnect and snapshot-rebuild logic for the quote book.
• An automated test harness that replays recorded sessions, so a change in a field or a symbol format shows up as a failing assertion before it reaches your data.
• A batch-versus-stream sync design covering how positions and fills back-fill on first run and stay current after.
• An OpenAPI/schema description of the normalized surface and a protocol-and-auth-flow report covering the token and session chain as it applies here.
• Interface documentation plus data-retention and entitlement guidance for the exchange data you receive.

Routes to the data

Authorized protocol analysis and interface integration

The app talks to its backend over a FIX 4.4 market-data dialect for quotes and a Google Protocol Buffers feed over secure websockets for streaming, with separate calls carrying order and account state. We map that traffic and build a normalized client over it. This reaches everything in the table above and is the most durable option, because it tracks what the app itself relies on. This is the spine we would build on for QST.

User-consented session access

Operating inside a consenting account, the client reads the same orders, positions, alarms and watchlists the user sees. It is quick to stand up for a single book and pairs well with route one for the account-state half of the work.

Native carry-over as a fallback

QST already moves a user's saved settings and layouts between QST Desktop, QST Lite and QST Mobile. Where a project only needs that configuration rather than live trading data, reading the carry-over format is the lightest path. It does not reach quotes or fills, so it is a supplement, not a backbone.

Entitlements, consent, and who watches the data

This is a US futures and equities context, so two things govern the work. The broker behind the account is regulated by the Commodity Futures Trading Commission and the National Futures Association — the dependable legal basis for reading account records is the account holder's own authorization, captured and logged. The market data is the second piece: exchange quotes are licensed, not open. CME Group's data-licensing guidelines require non-display use to be declared and constrain how a feed reaches downstream applications, which directly affects redistribution. We scope the integration to stay inside those terms, keep entitlement counts honest, and arrange the declarations with you as part of onboarding. Access is consent-based, logged, and data-minimized, with an NDA where the engagement needs one.

Engineering details we plan around

Two notes that decide whether this integration holds up in production:

• Symbol composition and roll. Futures symbols carry a contract-month suffix and the active month rolls on a calendar. We map QST's symbol composition so a rolled contract links to its prior expiry, keeping order and position history attached to the right instrument rather than orphaning it on roll day.
• Two transports, two cadences, one store. Quotes arrive as a continuous push while account activity comes back as a delta page. We design the store so the streaming book and the polled activity reader recover independently, and a stale quote never gets mistaken for a stale fill.
• Quick account switching. The app moves fast between the accounts in a portfolio. We scope reads per account so a combined portfolio view and the individual account views both reconcile to the same numbers.

These are things the build accounts for; access to a session or a sandbox account is arranged with you during onboarding, not a hurdle to clear before we start.

Where teams point this integration

• Mirror a trading desk's open positions and P&L into an internal risk dashboard, refreshed off the activity delta.
• Archive every fill and order amendment to a compliance store with a complete, replayable audit trail.
• Feed live quotes and depth into a pricing or signal model that sits outside the app.
• Keep a trader's watchlists and price alarms in sync with another front-end they use.

Screens from the app

Vendor screenshots from the Play listing, useful for orienting on which surface each data domain comes from.

How this brief was put together

Mapped against the app's public description and listing, the futures and equity venue coverage it names, and the exchange data-licensing rules that constrain redistribution. Checked June 2026. Primary sources opened for this page:

• QST Mobile on Google Play — feature list, venue coverage, platform support.
• QST FIX market-data protocol documentation — the FIX 4.4 dialect and GPB websocket transport the platform runs.
• CME Group data-licensing policy and non-display FAQ — declaration and redistribution constraints on the market data.
• CME Group on the CFTC and NFA — the regulatory bodies over the broker side.

OpenFinance Lab — protocol mapping · 2026-06-07

Other platforms in the same execution stack

Traders rarely live in one terminal. These cover the same futures and equity instruments, and a unified integration often spans several of them. Listed for context, not ranked.

• CQG — institutional-grade quotes and low-latency execution; holds per-account orders and positions much like QST.
• Sierra Chart — charting and DOM-focused platform with its own data and order records per connected account.
• NinjaTrader — retail and professional futures platform with automation, market replay and account state.
• TradingView — web-based charting with watchlists, alerts and broker-linked order data.
• Rithmic R|Trader Pro — low-latency futures front-end whose feed and fills many other tools sit on top of.
• Quantower — multi-asset platform with order-flow visualization and per-account portfolio data.
• MultiCharts — quant-oriented platform with backtesting and live account positions.
• Bookmap — depth and liquidity visualization built on streaming market data and order events.

Questions integrators ask

Do quotes and order history reach us the same way?

No, and the client we ship treats them differently. Quotes and market depth arrive as a continuous stream over the Protocol-Buffers websocket the app uses, so they land tick by tick. Orders, fills, and positions come back as a delta page you read against a cursor, so a re-poll only carries what changed. The store is built so a dropped websocket and a missed poll heal independently.

Can you cover both the futures contracts and the NYSE, NASDAQ and AMEX equity symbols?

Yes. The same client subscribes across the futures venues the app lists (CME Group, ICE, KCBT, MGEX) and the equity exchanges (NYSE, NASDAQ, AMEX), per the app description. The work is mostly in symbol composition: futures symbols carry a contract-month suffix while equities do not, so the normalizer keys them apart.

How do CME market-data fees shape what we are allowed to receive?

Exchange data is licensed, not free to redistribute. CME Group's data-licensing guidelines require non-display use to be declared and scope how data feeds downstream applications. We design the integration to stay inside those terms and keep entitlement counts correct, and we sort the declarations out with you during onboarding rather than after the fact.

What happens to contract symbols when a future rolls?

A futures symbol like GCQ6 points at one expiry, and the active month moves on a schedule. We map QST's symbol composition so a rolled contract links back to its prior month, which keeps order and position history attached to the right instrument instead of orphaning it on roll day.

A first working client — the quote subscription plus the cursor-paged activity reader — typically lands in one to two weeks. Source-code delivery starts at $300 and is billed only after you have it running and are satisfied; or skip the build fee entirely and call our hosted endpoints, paying per call. Tell us which accounts and instruments you need covered and we will scope it: start a conversation.