Reading balances, positions and strategy P&L out of an ApolloBot account

Every fill ApolloBot routes to Binance, OKX or Bybit lands back in its own synced ledger within seconds — balances, open positions, order state and a running profit curve, stitched across as many as ten venues at once. That live, already-merged view is the thing an integrator actually wants out of the app, and it is the thing a screen does not give you. This brief maps where each piece of it sits, the authorized way to read it, and what we hand over.

ApolloBot connects to Binance, OKX, Bitget, Bybit, HTX, KuCoin, Gate.io, BingX, CoinW and BitMart through exchange API keys, per its Google Play listing, and runs trend-following, grid, trend-reversal, oscillation and arbitrage strategies side by side on the same account. So the data has two layers: per-venue truth at each exchange, and ApolloBot's roll-up plus strategy attribution on top. We read both.

Bottom line: most of what you need is reachable live and durably from the exchanges themselves, with ApolloBot's synced layer adding the per-strategy attribution that raw venue data does not carry. We lead with the exchange streams for freshness and layer the app's view on top for the strategy tags.

Where ApolloBot's numbers come from

Each row below is a real surface of the app, where it originates, how fine-grained it is, and what an integrator typically does with it.

Routes to the account data

Three routes apply here. They are not exclusive; the build usually combines the first two.

Scoped exchange APIs (the live spine)

The same keys a user already gives ApolloBot — read and trade scope, withdrawals off — pull balances, positions, orders and fills straight from each venue, and subscribe to its user-data WebSocket stream for real-time pushes. CCXT normalizes more than a hundred exchanges behind one interface, so Binance, OKX and Bybit collapse into a single shape. This is the most durable path: it rides documented venue APIs, not app internals. It gives raw per-venue truth, not ApolloBot's strategy tags. Effort is low to medium.

Authorized interface integration of ApolloBot's synced layer

Some things only exist inside the app: the merged balance roll-up, the strategy configs, and the per-strategy P&L attribution. We reach those by protocol analysis of the app's own traffic, run under the account holder's authorization — reverse engineering the request and response shapes for interoperability, then re-implementing them as a clean client. Effort is medium; it tracks app releases, so we schedule a periodic re-check against the live app rather than assuming the shapes stay frozen.

Native export (the coarse fallback)

Where the app offers a trade-log or CSV export, that is the lowest-effort path for a point-in-time pull. It is coarse and not live, so it suits a one-off backfill rather than an ongoing sync.

What we would actually build: the exchange streams as the live, durable feed for balances, positions and fills, with the app-side read layered on for strategy attribution and the merged view. The export sits in reserve for an initial history backfill.

What lands in your repo

The headline deliverable is code that runs, not a document set:

• Runnable Python and Node.js source — user-data stream consumers and REST pollers that normalize ApolloBot's balances, positions, orders and fills across the linked venues into one schema.
• Webhook / stream handlers for fill, order-update and position-change events, each keyed on a venue, order and trade id, with a re-auth helper for the listenKey or stream login per venue.
• An automated test suite that replays recorded venue streams and fixtures, covering the normalized fields and the per-venue shape mapping.
• A batch-backfill plus real-time sync design: seed history once from export or REST, then keep current from the stream.
• An OpenAPI / Swagger spec for the normalized endpoints we expose to your side.
• A protocol and auth-flow report covering the key-signing and listenKey/token chain as it applies per venue.
• Interface documentation and short data-retention guidance for the fields you keep.

A consumer for the fill stream

Binance gates its user-data stream behind a listenKey you keep alive on a timer; OKX and Bybit sign a stream login instead. The consumer below normalizes a futures fill into one shape regardless of venue. It is illustrative — the exact field names get confirmed against each venue's stream during the build, not guessed.

# Normalized fill consumer, fanned out from the venues ApolloBot links to.
# One shape for Binance / OKX / Bybit; strategy tag preserved.

async def on_user_event(venue, raw):
    if raw.get("e") != "ORDER_TRADE_UPDATE":      # Binance USDⓈ-M shape
        return
    o = raw["o"]
    yield Fill(
        venue   = venue,                          # "binance" | "okx" | "bybit"
        symbol  = o["s"],                         # e.g. "BTCUSDT"
        side    = o["S"].lower(),                 # buy | sell
        qty     = Decimal(o["l"]),                # last filled qty
        price   = Decimal(o["L"]),                # last filled price
        fee     = Decimal(o.get("n", "0")),
        strategy= tag_strategy(o["c"]),           # clientOrderId -> CTA/DCA/Alpha
        ts      = o["T"],
        event_id= f'{venue}:{o["i"]}:{o["t"]}',   # de-dupe a replayed socket frame
    )

# Underneath the stream, a REST reconcile catches anything a dropped
# socket missed:  GET /fapi/v2/account  (signed: HMAC-SHA256 over the
# query string, X-MBX-APIKEY header) -> compare positions and balances.

Three things teams wire this into

• One portfolio NAV. Roll the ten venues' balances and open positions into a single number, refreshed live, for an internal treasury or fund dashboard.
• A risk mirror. Stream position changes into a risk engine that trips when aggregate exposure or drawdown crosses a limit — the same kind of guardrail ApolloBot enforces per strategy, surfaced where your desk can see it.
• Accounting export. Pull the full fill history with fees and strategy tags into a ledger for realized-P&L and cost-basis, split per strategy and per venue.

Engineering we handle up front

The hard parts of this integration are specific to ApolloBot's multi-venue, multi-strategy shape. We account for them in the build:

• Per-venue shapes get reconciled. Binance, OKX and Bybit each describe a position and a fill differently — futures versus spot wallets, funding and margin fields, symbol conventions. We map them to one schema and check ApolloBot's rolled-up view against each venue's own numbers, so a mismatch surfaces where we can catch it.
• Key scoping is arranged with you. The build runs on read and trade scopes with withdrawals disabled and, where the venue allows it, an IP allowlist. We set those keys up with you when we wire the integration; it is part of the engagement, not something handed over before we start.
• Strategy attribution is preserved. ApolloBot runs CTA, DCA, Alpha, Beta and arbitrage concurrently on one account. We carry the originating strategy tag through to every fill and P&L row, so the export keeps attribution instead of collapsing into a single blended figure.

Authorization and the MiCA backdrop

Consent is the dependable basis here: you authorize access to your own ApolloBot and exchange data, and we work to that authorization — logged, data-minimized, under NDA where you need one. Read-only or read-and-trade scope, never withdrawal.

The connected exchanges sit under a real regime. In the EU, the Markets in Crypto-Assets Regulation (MiCA) became fully applicable on 30 December 2024, with a grandfathering window for existing providers running to 1 July 2026, per ESMA. ESMA's 28 November 2025 statement on MiCA data standards sets how trading platforms keep records — order-book records in JSON following ISO 20022 methodology — which shapes the formats the venue side hands back. Crypto trading-bot data is not covered by bank open-banking or account-aggregation schemes, so consent of the account holder, not a data-sharing mandate, is what the integration rides on.

Pricing and how a build runs

A first ApolloBot build is a working balance, position and fill feed plus the source that produces it, handed over in one to two weeks. Take that source outright from $300: runnable code and the docs around it, billed only after delivery once you have looked it over and you are satisfied. Prefer not to host anything? Call our endpoints instead and pay per call, with no upfront fee. You bring the app name and what you want from its data; access and the compliance side are arranged with you along the way.

Tell us what you need from ApolloBot →

Screens we worked from

Listing screenshots, as published on the app's store page. Open any to enlarge.

How this brief was put together

Checked on 15 June 2026. The connected venues and feature set come from ApolloBot's Google Play listing; the exchange-side mechanics are read from CCXT's unified API documentation and Binance's request-security reference; the EU backdrop is taken from ESMA's November 2025 MiCA data-standards statement.

Compiled by OpenFinance Lab — crypto exchange integration engineering · 2026-06-15.

Other bots in the same integration problem

Same category, same kind of account state — useful when one integration has to span more than ApolloBot. Listed for context, not ranked.

• Pionex bundles trading bots inside its own exchange, so balances, bot configs and fills sit on a single venue's account.
• 3Commas connects external exchange accounts by API and holds DCA and grid bot state, deal history and aggregated P&L.
• Cryptohopper is a cloud bot that stores strategy templates, open positions and trade history across linked exchanges.
• Bitsgap aggregates multiple exchange accounts for grid and arbitrage bots, keeping orders and portfolio data in one dashboard.
• TradeSanta is a cloud bot holding bot configurations, open deals and exchange-linked balances.
• Coinrule runs rule-based automation and stores user strategies and execution logs against connected exchanges.
• Altrady is a multi-exchange terminal that consolidates balances, orders and analytics across venues.
• Hummingbot is an open-source market-making and arbitrage bot that keeps strategy config and fills on the user's own host.
• Kryll is a visual strategy builder that stores backtests, live bot state and execution history.

Questions integrators ask about ApolloBot

Can ApolloBot fills and position changes arrive in real time, or only on a poll?

Real time. The exchanges ApolloBot links to expose user-data WebSocket streams, so fills, order updates and position changes push within seconds; we run a periodic REST reconcile underneath so a dropped socket does not lose anything. Polling on a cursor is the fallback for a venue that limits streams.

I run ApolloBot across Binance, OKX and Bybit at once — does the feed merge them?

Yes. Each venue's balances, positions and fills are mapped to one schema and rolled into a single account view, with the source venue kept on every row so you can still split the numbers back out by exchange.

Does the export keep P&L separated by strategy — CTA, DCA, arbitrage?

It does, where ApolloBot tags the originating strategy on its orders. We carry that tag through to each fill and P&L row so attribution is not flattened into one blended number across the trend-following, grid and arbitrage strategies running on the same account.

Do you need my exchange API keys with withdrawal access?

No. Read and trade scopes are enough, withdrawals stay disabled, and the keys are set up with you when we wire the integration — IP-allowlisted where the venue supports it. The read is authorized by you as the account holder.