What Pynova holds behind its login, and the authorized route to it

Every Pynova account sits behind a single login that fronts a moving balance: deposits credit in, automated-strategy returns accrue, invite bonuses post, and withdrawals queue out. None of that is visible to anyone but the logged-in user. A third party that needs to reconcile, mirror or audit those numbers has to read the app's own client-to-server traffic — that traffic is the integration surface, and reaching it cleanly is the work this brief describes.

Pynova is not a bank inside an open-banking regime, so the dependable way in is to observe the app's own requests on an account you authorize, document the protocol, and rebuild the calls as clean code. We treat the referral ledger and the money ledger as separate problems because the app does — the bottom line is that all five headline surfaces below are readable from a single authenticated session.

Data behind the login

Each row reflects a surface this specific app exposes to its own client, named the way the app frames it, not a generic finance checklist.

Routes in

Three routes genuinely apply to Pynova. Each is described by what it reaches, how much work it is, how long it survives, and what we set up to run it.

Protocol analysis of the mobile client

We capture the app's requests in an authorized test session, document the login, session and account endpoints, and rebuild them as code. This reaches every surface in the table — balance, recharge, returns, referral, withdrawals. It is the most complete route and the one we recommend here. Durability is moderate: short-lived sessions and occasional response changes are expected, and we account for that in maintenance rather than treating it as a surprise. Access is arranged with you during onboarding; the build runs against an account you control.

User-consented credential access

Where the data subject consents, the integration signs in with their credentials and reads the same endpoints on their behalf, scoped to exactly what is needed. This suits servicing one's own users or a consenting partner. Lighter to stand up than a broad capture program; bounded to the consenting account's view.

Native export as a fallback

If a user-facing export or statement exists in the app, it can seed a reconciliation baseline while the live integration is built. It is a backstop, not the spine — coverage is whatever the app chooses to put in an export, which is narrower than the live account state.

The recommendation for Pynova is plain: build on protocol analysis of the client, fall back to consented credential access where the work is per-user, and use any native export only to bootstrap. The first route is the only one that returns the full picture in one pass.

What you get

Deliverables are tied to Pynova's actual surfaces, not a template list.

• An OpenAPI/Swagger specification covering login, account summary, recharge history, referral ledger and the withdrawal list as observed.
• A protocol and auth-flow report: how the bearer token is issued, how short-lived the session is, the refresh path, and the recharge-gated state on the dashboard.
• Runnable source for the key endpoints in Python and Node.js — authenticate, pull the account summary, page the withdrawal list, read the invite ledger.
• Automated tests, including the pre-funding (NEED_RECHARGE) and post-funding response shapes so both states are exercised.
• Interface documentation an in-house team can maintain, plus data-retention and consent-handling guidance scoped to the regimes below.

On the wire

The shape below is illustrative of how this class of client behaves; exact paths and field names are confirmed during the build against the consenting account.

# Pynova mobile client -> backend, authorized capture.
# Illustrative shapes; exact endpoints/fields confirmed per engagement.

POST /api/user/login
  { "account": "<email|phone>", "password": "<...>" }
  -> 200 { "token": "<bearer>", "uid": 90xxxx, "locale": "en" }

GET /api/account/summary           Authorization: Bearer <token>
  -> 200 {
       "balance":      "0.00",   # spendable wallet
       "recharge_sum": "0.00",   # lifetime deposits
       "profit_today": "0.00",   # accrued strategy return
       "invite_bonus": "0.00",   # referral ledger total
       "state": "NEED_RECHARGE"  # gates the strategy view
     }

GET /api/withdraw/list?page=1      Authorization: Bearer <token>
  -> 200 { "rows": [
       { "id":..., "amount":"...", "status":"PENDING|PAID|REJECTED", "ts":... }
     ] }

# Error contract we handle:
#   401            -> token expired; re-run login (sessions are short)
#   body code 1003 -> recharge required; summary still valid, strategy view empty

Worked examples

• Nightly reconciliation: pull each account's balance and lifetime recharge, diff against an internal ledger, raise an exception on drift.
• Payout mirror: poll the withdrawal list, project PENDING to PAID transitions into a back-office dashboard, flag requests stuck past a threshold.
• Partner-payout audit: read only the invite bonus total and per-invite records to verify referral claims, without touching trading data.
• Portfolio snapshot: capture accrued strategy return per account on a fixed cadence for aggregation across platforms.

Consent and the regulators

On the available evidence Pynova faces Indian users, so two regimes shape the work. India's Digital Personal Data Protection Act 2023 — with the DPDP Rules 2025 phasing in toward the substantive provisions taking effect, per the compliance guidance cited below — treats a platform that decides what user data is collected and why as a data fiduciary. That brings affirmative consent before processing and the data principal's rights to access, correction, erasure and grievance redress. Separately, virtual-digital-asset service providers were pulled under the PMLA AML/CFT framework, with FIU-IND registration as a reporting entity and FIU-IND's VDA AML/CFT guidance refreshed in early 2026, per the CMS India crypto-regulation guide. We work to the strict reading of both: consented access only, scoped to the fields a use case needs, with consent records and request logs kept, data minimized, and an NDA in place where the engagement calls for one. Consent for this kind of integration is bounded and revocable; we design the sync so revocation stops collection rather than lingering.

Engineering judgment

Two things about this specific app shape the build, both handled on our side.

Pynova gates the strategy view behind a recharge step, so a fresh account returns a summary with a NEED_RECHARGE state and an empty returns view. We map the pre-funding and post-funding response shapes as distinct cases, so the integration returns a coherent account view in either state instead of treating the empty pre-deposit payload as a failure.

The client is multi-language, and the same balance and reward values surface under localized labels. We key the parser off stable response identifiers, never the displayed strings, and re-validate the locale map during maintenance so a UI language change does not silently shift the extracted schema. The same maintenance pass covers the short session lifetime — we model the withdrawal record as a PENDING/PAID/REJECTED state machine and reconcile on each sync, so a queued payout is never double-counted against the wallet balance.

Interface evidence

Public store screenshots, for reference to the surfaces described above.

Comparable apps

Same-category apps an integrator often has to unify alongside Pynova. Listed for ecosystem context, not ranking.

• ZebPay — Indian crypto exchange holding spot balances, trade history and INR deposit/withdrawal records behind an account.
• Pionex — exchange with built-in trading bots; holds wallet balances and per-bot order and position state.
• 3Commas — keeps connected-exchange keys, bot configurations and trade logs across linked accounts.
• CryptoHopper — stores bot strategies, trade history and portfolio snapshots per user.
• TradeSanta — holds bot orders and per-exchange balances for automated strategies.
• Uphold — multi-asset balances, transaction history and staking positions in one account.
• Coinbase — account balances, conversion and transaction history, recurring-buy records.
• Kraken — spot and funding balances, account ledgers and staking-reward entries.
• Bitrue — wallet balances, deposit/withdrawal records and yield-position state.
• Earnova — markets daily USDT-earning balances and referral payouts, the closest behavioral peer to Pynova's reward framing.

How this was checked

Mapped on 16 May 2026 from Pynova's Google Play listing and its stated features, third-party review coverage of how its recharge and withdrawal flow behaves, and primary regulatory guidance for an India-facing crypto investment app. Developer identity, install count and version are not disclosed in what was reviewed and are not asserted here. Public reviews of this app are mixed; we work only under a client's authorization on accounts they control and make no claim about the operator. Key sources: Google Play listing, AppBrain app intelligence, DPDP compliance for investment platforms, CMS India crypto-regulation guide.

Pynova interface mapping — OpenBanking Studio integration desk, 16 May 2026.

Questions integrators ask

Pynova hides the strategy view until an account has recharged. Does that block reading the data?

No. The account summary, lifetime recharge total and referral ledger respond before any deposit; the response just carries a NEED_RECHARGE state. We map the pre-funding and post-funding shapes separately so the integration returns a coherent view in both, instead of treating an empty pre-deposit payload as an error.

If Pynova users are in India, which rules govern handling their data?

Two regimes apply. India's Digital Personal Data Protection Act 2023, with the DPDP Rules 2025 phasing in, treats a platform that decides what user data is collected as a data fiduciary owing consent, access, correction and erasure. Separately, virtual digital asset services fall under the PMLA AML/CFT framework with FIU-IND registration. We build to consented access and data minimization against both.

Can the invite/referral bonus ledger be pulled apart from the trading balance?

Yes. The referral bonus total is a distinct field in the account summary and the invite records list separately from wallet movements, so partner-payout reconciliation can run without touching strategy or recharge data.

Pynova's withdrawal queue and accrued returns move during the day. How current is the data you hand back?

The withdrawal list and accrued-return field are read live on each sync, and the withdrawal record is modeled as a PENDING/PAID/REJECTED state machine so a queued payout is reconciled rather than double-counted. Sync cadence is set to whatever the use case needs, from on-demand to a short polling interval.

One engineer maps one app per engagement, and Pynova is a one-to-two-week build. Payment is simple and described here only once: source-code delivery starts at $300 and is paid only after delivery, once you have the runnable code and are satisfied with it; or use our hosted endpoints and pay per call with nothing upfront. Give us the app name and what you need from its data — access and the compliance paperwork are arranged with you as part of the work. Start at /contact.html, or read more at openbankingstudio.com.