Doex Pro carries spot books, high-multiple futures, and a copy desk behind one session

DOEX INC. publishes a single mobile surface — Doex Pro — that fronts a spot exchange, a futures engine the platform markets at high notional multipliers, and a one-click copy-trading desk. Three data planes share one signed-in account, but they don't share a schema. Anyone integrating against this app is really integrating against three sub-systems wearing the same session.

Per the exchange's own support article on its US Money Services Business issuance, DOEX has held a FinCEN MSB registration since 2023, with a Canadian FinTRAC registration alongside it and trading operations advertised across South Korea, Taiwan, and Indonesia. The regulatory perimeter matters more for how the consent record is kept than for which fields actually leave the app — those are determined by the surfaces the user can see and the basis under which they sign us in.

What data sits behind a Doex Pro login

The mapping below uses the app's own tab names where the store screenshots make those names visible. Anything not listed here is either public (mark prices, order book) or we don't try to mirror it.

The route from a consenting account out to a clean feed

Route 1 — authorized signed-interface integration

We instrument the app under a consenting account, decode the signed backend protocol, and rebuild the calls in code. Reach is the full read: spot wallets, futures positions, every order and fill, the copy-trading mirror ledger, and the KYC level. Effort is moderate — usually under two weeks once we have a consenting account. Durability is middling on its own and good with the weekly re-validation pass we wire in.

Route 2 — user-consented session delegation

The account holder authorizes us as their agent in writing, signs us in, and we operate the app's own interface from within their session. Reach is the same as Route 1, plus interactive flows that would otherwise need a person. Effort is a touch lower (the user does the signing). Durability tracks how long the user keeps the session healthy and how often the platform asks for re-attestation.

Route 3 — native exports plus on-chain reconciliation

The history screens produce downloadable trade and transfer files. Deposits and withdrawals have on-chain counterparts that match by transaction id. Reach: trade history, deposits, withdrawals — not live positions. Effort is low. Freshness is whatever the user clicks Export.

Route 1 carries the spine when freshness matters — live positions, copy attribution, the futures mark loop. Route 2 sits beside it for accounts where the owner prefers to keep the credentials in their own hands. Route 3 is the cold reconciliation lane behind both.

A working slice — signed read + a user-orders stream

Sketch, not production. The hostname and signing scheme below were confirmed during the build against a consenting test account; the constants here are illustrative.

# Signed read of spot balances + open futures positions,
# plus the user-orders stream where mirrored copy fills arrive.
import hmac, hashlib, time, json, requests, websockets

BASE = "https://api.doex.com"   # path captured during the build
KEY, SEC = creds()              # vaulted; never logged

def sign(query: str) -> str:
    return hmac.new(SEC.encode(), query.encode(),
                    hashlib.sha256).hexdigest()

def account_view():
    ts  = int(time.time() * 1000)
    q   = f"timestamp={ts}"
    sig = sign(q)
    r = requests.get(
        f"{BASE}/v1/account?{q}&signature={sig}",
        headers={"X-DOEX-KEY": KEY},
        timeout=8,
    )
    r.raise_for_status()
    return r.json()
    # => { spot:[...], futures_positions:[...], kyc_level:str }

# Fills arrive here. Mirrored orders carry master_order_id and
# the lag we observed at capture time; attribution downstream
# does not have to re-derive either.
async def fills():
    url = BASE.replace("https", "wss") + "/stream"
    async with websockets.connect(url) as ws:
        await ws.send(json.dumps(
            {"op":"subscribe","channel":"userOrders"}))
        async for msg in ws:
            yield json.loads(msg)

What lands at the end of the build

• An OpenAPI 3.1 description of the read slice we agreed to — account view, positions, orders, fills, copy ledger, KYC level — with examples drawn from a real consenting account, PII redacted at capture time.
• An auth-and-rotation report. The full chain from login to a request-ready signed call, including any device-fingerprint payloads and how the platform signals key rotation.
• Two runnable client modules — Python (httpx + websockets) and Node.js (undici + ws) — with the user-orders stream wired to the same normalization the REST path uses.
• A pytest suite with VCR-style recorded fixtures so CI never hits the live exchange.
• A markdown interface guide written for an engineer who has never seen the app and is reading on a Monday.
• A compliance memo: what we kept on capture, what we discarded at the boundary, where the consent record lives, and how revocation is honoured.

What the build has to account for

The interesting parts of a Doex Pro pull are not the wallet read — that is straightforward once the auth flow is captured. The interesting parts are the seams between the sub-systems. We bake the following into the scope so they don't surface as surprises in week three.

• Spot and futures live in separate sub-accounts on the exchange's books. We normalize them into one account_view with a wallet_kind discriminator so downstream code can fold or split without re-deriving the model.
• Copy-trading attribution. Each mirrored order fires after its master order with a settlement lag. We tag every mirror with master_order_id and the captured lag, so follower P&L attributes back to the strategy and a copier doesn't double-count a fill the broker also reports.
• Per-market precision. Lot and tick sizes differ across spot pairs and across futures contracts, and the support center keeps publishing new listings (GOAT/USDT was one of the recent ones). We capture the per-market metadata at build time so quantities and prices round where the exchange rounds them.
• Re-validation cadence. Mobile-fronted exchanges ship app updates that change signing payloads. We bake a weekly re-validation pass into maintenance that diffs the payload shape and pings before production breaks.
• KYC isolation. KYC level and document references travel on a separate, shorter-retention channel than trade data. The trade pipe is hot; KYC is cold and access-controlled.

MSB perimeter, KYC, and the consent that carries the build

Doex itself sits inside two money-services-business perimeters — FinCEN in the United States, FinTRAC in Canada, per the exchange's own help-center article on the US issuance. Those regimes govern how Doex onboards, monitors, and screens its users. They do not govern us, and we don't operate inside them. Our basis is narrower and simpler: the account owner's signed consent.

The consent record carries scope (which fields, which sub-account), purpose (what the data is for), retention (how long we keep it), and revocation (who can pull the plug and how fast). For personal data inside the pull, the regional regime that applies to the user applies to us too — GDPR for EU residents, PIPEDA in Canada, the relevant state-level law in the United States. None of this is bank open-banking; account information service rules do not enter the picture. Crypto exchanges do not currently fall under that framework, and we don't pretend otherwise.

Operationally: signing keys and session material are vaulted on first capture and never appear in logs or fixtures. Captures are redacted at the boundary, not after.

Cost and how the work runs

Hand-off looks like a git repository, a written interface guide, a passing test run, and a live call against your consenting account. Source-code delivery starts at $300 and is billed only after that hand-off, only if you're satisfied with what we shipped. The hosted-API route routes your calls through our endpoints with no upfront fee — you pay per call and stop when you stop calling. Build cycle is one to two weeks from the day a consenting account is in scope. Start a scope here and we'll come back with a concrete plan within a working day.

What the app looks like behind a login

Six screens from the public store listing. They are mostly useful for naming the data domains the way the app names them — the Assets, Trade, and Copy tabs the integration walks.

What we checked before scoping this

Doex Pro's Play Store listing and App Store listing, the exchange's own support article confirming the US FinCEN MSB issuance, and the CoinMarketCap exchange profile that lists current pairs and reported volume. The Doex help center's recent listing announcements (the GOAT/USDT spot-pair note among them) confirmed that the spot-pair surface is the one we model.

Other crypto exchange apps integrators ask about

Crypto exchange integrations cluster around the same primitives — wallets, orders, fills, positions, sometimes copy ledgers — so a Doex Pro build often sits beside one of these on the client side.

• Binance — the largest centralized venue by volume; the same spot/futures sub-account split applies, with funding rates as an extra pull.
• Coinbase — US-listed, retail-leaning; integrators usually pull fiat-on-ramp orders and tax-grade trade history.
• Kraken — long-tenured exchange with strong derivatives; spot and futures sit in parallel sub-accounts as on Doex.
• Bybit — derivatives-first venue with copy trading; the copy-attribution model is directly comparable.
• OKX — spot, futures, and earn products; integrators usually pull the unified-account view first.
• KuCoin — altcoin breadth; per-pair metadata matters more here than on a top-five venue.
• Bitget — copy trading as the flagship product; mirror-order back-references look similar to Doex's.
• Crypto.com — retail app with a card product on the side; card transactions sit on a separate ledger from trades.
• Phemex — contract-heavy; perpetual position data is the primary pull.
• BingX — spot, futures, and copy; the data model is closely comparable to Doex Pro.

Things integrators ask before we start

Will the integration reach futures positions and not just spot balances?

Yes. Futures positions sit behind the same authenticated session as the spot wallet, so the build covers per-contract size, entry price, mark price, unrealized P&L, and margin multiplier alongside per-asset spot balances.

Where does copy trading fit in the data model?

Each mirrored order carries a back-reference to its master order id and a settlement lag; we annotate both during normalization so follower P&L attributes back to the strategy that drove it.

Does Doex's MSB licensing constrain what an integrator can pull?

The MSB perimeter sits on the exchange side, not on the integration. From our side the work runs against a consented user account, respects the platform's terms, and logs access for the consent record.

Mapping reviewed 2026-05-29 · OpenBanking Studio integration desk.