The live-quote feed behind a candlestick trading game, and how we reach it

More than four million installs sit behind this practice simulator, marketed as Day Trading Academy, per its Google Play listing. The part worth integrating is not the lessons screen — it is the real-time feed the simulator pulls before it draws a chart, plus the practice records a learner builds up while using it. That feed runs across stocks, crypto and forex, and the app itself never asks a buyer to risk money, which changes what the integration is and is not.

Here is the bottom line. The high-value surface is the market-data stream the simulator consumes — per-symbol candles across timeframes and asset classes — followed by the lesson and pattern-quiz content service and the RevenueCat entitlement signal. Progress, quiz scores and the simulated trade ledger look client-side, since the published privacy policy describes no mandatory account. We would build around the captured feed as the spine and read the on-device records separately, normalizing both into one schema.

What this app keeps, and where each piece actually lives

The surfaces below are drawn from the store description, the official site and the privacy policy. The origin column matters here, because not everything in a practice app sits on a server.

Two routes that fit a practice-trading app

This is not a regulated money flow, so a consent-scheme route does not apply. Two routes do.

Protocol analysis of the app's own traffic

We observe the simulator under authorization, separate the market-data and content calls from the AdMob and Firebase noise, and reconstruct the request shapes, the auth exchange and the token-refresh cycle. Reachable: the live and historical candle feed, the lesson and pattern catalog, the entitlement check. Effort is moderate; durability is good for the data envelope and weaker around the client build, which ships often. This is the route we would recommend as the backbone — it is the only one that yields the real-time stream.

On-device read for client-side records

Progress, quiz history and the simulated ledger appear to live on the device, not behind a synced account. We read those from a consenting device or an instrumented build and normalize them. Reachable: a learner's full local history. Effort is low once a consenting instance is available; durability tracks the app's local storage format. We treat this as a companion to the first route, not a replacement, and we are honest on the page about which fields are local.

Native export, where the app exposes one, is folded in as a convenience fallback for the records a user can already pull themselves — useful for spot-checking, not a substitute for the captured feed.

What a captured request actually looks like

The simulator fetches candles per instrument and timeframe before rendering. The shape below is illustrative and is the kind we confirm during the build, not an official contract.

# Illustrative — request shape confirmed during a protocol-analysis build.
# One envelope serves every asset class; the chart asks per symbol + timeframe.

GET /v2/candles?symbol=AAPL&asset=stock&tf=5m&limit=300
Host:  <market-data host resolved from the app's traffic>
Authorization: Bearer <session token from the app's auth exchange>
X-Client: dta-android/2.2.x

200 OK
{
  "symbol": "AAPL",
  "asset": "stock",
  "tf": "5m",
  "candles": [
    { "t": 1715800800, "o": 189.42, "h": 189.91, "l": 189.10, "c": 189.66, "v": 51234 }
    /* ... */
  ]
}

# crypto and forex reuse the same envelope with asset="crypto" | "forex".
# token refresh is a separate POST; a 401 triggers one refresh + retry,
# then the symbol is requeued for the next poll rather than dropped.
      

The error path is the part that earns its keep: market-closed gaps, partial candle windows and refresh races are where a naive reimplementation drifts, so the captured behavior is documented field by field.

What lands at the end of the build

Each deliverable maps to a surface above, not a generic checklist:

• OpenAPI specification for the candle feed and content endpoints, with the asset-class parameter, timeframe set and pagination documented.
• Protocol and auth-flow report covering the token exchange, the refresh cycle, the RevenueCat entitlement check and the headers the client sends.
• Runnable source in Python or Node.js for the key endpoints — feed polling with backoff, candle normalization across stocks, crypto and forex, and the on-device record reader.
• A normalized schema that collapses the three asset envelopes and the local progress fields into one model, so a consumer is not branching per asset class.
• Automated tests against recorded fixtures, including the 401-refresh path and market-closed gaps.
• Interface documentation plus data-retention and consent guidance written for a non-broker learning app.

Privacy footing for a non-broker trading game

No client funds, no settled trades, no brokerage account — that single fact decides the compliance posture. This is a data-protection question, not a financial-regulation one, and there is no AIS or open-banking scheme to invoke. The app's published privacy policy collects IP address and usage patterns and names five third parties: AdMob, Google Analytics for Firebase, Firebase Crashlytics, OneSignal and RevenueCat. Deletion is handled by writing to support@kovets.com; the policy describes no explicit GDPR or CCPA framework, and the developer's operating jurisdiction is not publicly disclosed and is not asserted here. We work to whichever data-protection regime the integrating party operates under, keep consent and access records, minimize what is captured to the data domains in scope, and sign an NDA where the engagement calls for one.

Engineering details we plan around

These are the things that decide whether the integration holds up, written as what we handle:

• Progress and the simulated ledger look device-local rather than account-synced, so we design the export around an on-device read against a consenting instance instead of expecting a server endpoint to return a learner's history.
• The feed is the moving part: candle cadence and the symbol set differ by asset class, so we map stocks, crypto and forex separately and present one normalized model rather than leaking three.
• Premium-only surfaces sit behind RevenueCat, named in the privacy policy, so we wire the entitlement check against the captured RevenueCat exchange and reproduce gated screens correctly.
• The trace is noisy — AdMob, Firebase and OneSignal calls interleave with the data calls — so we filter the capture down to the market and content endpoints before anything is documented.
• The client ships frequent builds (the listing shows 2.2-series versions), so we re-validate the captured flows whenever a new build changes the front end, and access to a test instance is arranged with you during onboarding.

How a project with us runs

You hand us the app name and what you want out of its data; access and the compliance paperwork are arranged together as part of the work. From there the choice is plain. One model is source-code delivery starting at $300: you receive the runnable integration, the spec, the tests and the documentation, and you pay once the build is delivered and you are satisfied with it. The other is a hosted API you call and pay per call, with nothing upfront. Either way the cycle runs one to two weeks.

Keeping a captured feed from going stale

A real-time feed integration rots quietly if no one watches it. The build includes a heartbeat against the candle endpoint so a changed host or auth shape is caught early, dedup on overlapping tick windows, and explicit handling of weekend and after-hours gaps so a flat segment is not mistaken for a dead feed. When the client ships a new version, the recorded fixtures are replayed and the differences surfaced before they reach a consumer.

Sources, and when this was checked

This mapping rests on the public store listing, the app's official site and its published privacy policy, read on 16 May 2026. The privacy policy is the strongest signal here — it names the billing and analytics stack and the absence of a mandatory account, which is what shapes the route. Primary sources: Google Play listing, daytradingacademy.app, the app privacy policy.

Mapped by the OpenBanking Studio integration desk, 2026-05-16.

Other practice-trading apps in the same integration bucket

Same data shape, different front doors — listed for ecosystem context, not ranking:

• Trading Game - Stock Simulator — virtual portfolios and practice trades driven by real-time quotes, the closest analogue to this app's simulated-ledger and feed pairing.
• Wall Street Survivor — a $100k virtual account trading real stocks, ETFs, crypto and options under live conditions, with contest standings.
• Investopedia Stock Simulator — virtual portfolios, watchlists and game rankings tied to real market quotes.
• Webull paper trading — paper positions, watchlists and live candlestick charts behind an account.
• Moomoo paper trading — virtual cash positions across stocks, options and futures with account-bound history.
• Invstr — a virtual portfolio plus global competitions, with optional broker linking once a user is ready.
• HowTheMarketWorks — classroom contests with virtual portfolios and graded trade history.
• MarketWatch Virtual Stock Exchange — custom and public trading contests with portfolio and ranking records.
• thinkorswim paperMoney — a simulated brokerage account with order and position history.

A buyer integrating several of these usually wants one normalized model spanning quote feed, simulated ledger and progress — the same schema work this app needs.

Screens we worked from

Store screenshots, used to confirm which surfaces the app actually renders. Tap to enlarge.

Questions an integrator tends to ask first

The simulator covers stocks, crypto and forex separately — does one integration give us all three?

Yes. The captured feed uses one request envelope with the asset class as a parameter, so stock, crypto and forex candles arrive in the same shape. We normalize each asset class into a single schema, including the options surface the Play listing mentions, so the integrator works with one model instead of three.

Our learners' progress seems to sit on the phone rather than in an account — can you still export it?

Yes. The published privacy policy describes no mandatory account, so lesson completion, quiz scores, streaks and the simulated trade ledger are read from app storage on a consenting device or an instrumented build, then normalized into a portable history. We say plainly which fields are client-side rather than server-synced.

Is this regulated the way a brokerage data integration would be?

No. There is no real money, broker account or settled trade behind this app — it is a practice simulator. The compliance question here is data protection, not securities regulation: the privacy policy names AdMob, Firebase Analytics and Crashlytics, OneSignal and RevenueCat, collects IP and usage data, and handles deletion by email. We work to that footing with consent records and an NDA where needed.

We already run RevenueCat for our own billing — can the entitlement mapping line up with ours?

Yes. RevenueCat is named in the app's privacy policy as its subscription layer, so the premium-state check is part of the captured exchange. We map that entitlement signal to product and renewal fields you can reconcile against your own RevenueCat configuration.