Reaching a Univest user's holdings, calls and P&L through authorized access

Univest carries three SEBI registrations at once — research analyst, stockbroker and investment adviser (per univest.in) — and that split is the first thing the data model has to respect. A user opens one app, but behind it sit two different kinds of record: advice that an analyst issued, and trades that a broker executed. The portfolio tracker then sits on top, scoring each holding Buy, Sell or Hold. For anyone trying to mirror a Univest account into a wealth dashboard, a CRM, or a signal pipeline, the work is mostly about reading those layers cleanly and keeping them apart.

The route we would actually take leans on the authorized app session for the advisory and portfolio surfaces, because that is where Univest's distinctive data lives and nothing else carries it. Where the goal is reconciling demat positions, the Account Aggregator network is the cleaner, consent-backed path. Both are arranged with you during onboarding; neither is something you need to have in place before we start.

What sits behind a Univest login

Each row below is a surface the app actually exposes to its own user. Granularity reflects how the data is presented in-app, confirmed against the Play Store listing and univest.in during the mapping.

How the data is reached

Authorized app-session interface integration

We analyse the app's own traffic under your authorization and reconstruct the request/response contract for the advisory feed, the portfolio tracker, subscription state and the alert stream. This reaches everything that is unique to Univest. Effort is moderate; durability depends on the front end staying stable, which we account for in maintenance. Access is set up with you — a consenting account, credentials handled under NDA — as part of the build, not before it.

Account Aggregator (RBI) for securities holdings

Where the objective is reconciling demat and securities positions, the RBI Account Aggregator network gives a consent-driven, regulator-backed feed once the relevant financial information provider is live. SEBI-regulated entities began joining as FIPs from 2023, so investment data is now in scope. This route is durable and clean but narrower — it carries holdings and transactions, not analyst calls. We set up the consent flow and AA connection during onboarding.

User-consented session access

For a single-account proof of concept, we drive an authenticated session against the consenting user's own account and read exactly what they see. Quick to stand up, useful for validation, and a good way to confirm field shapes before committing to the full interface build.

Native alert capture

As a fallback, the WhatsApp and Telegram alert channels can be captured as a structured event source. It is the lightest path and pairs well with the session route when alerts are the priority.

For most engagements the app-session route does the heavy lifting because the advisory and rating data is the point, and we add an Account Aggregator feed when demat reconciliation matters. That pairing is what we would propose here unless your use case is alerts-only, in which case the capture route alone is enough.

A working example

Illustrative only — field names are confirmed against a live, consenting account during the build, not guessed here. This sketches the session token exchange and a pull of the recommendation feed, normalized so an exit update folds into the existing call record.

POST /v2/auth/session            # authorized session, token chain confirmed at build time
  body: { device_id, refresh_token }
  -> 200 { access_token, expires_in: 1800 }

GET  /v2/advisory/calls?status=open
  Authorization: Bearer <access_token>
  -> 200 {
       "calls": [
         { "call_id": "RA-48217",
           "segment": "FNO",
           "instrument": "NIFTY 24500 CE",
           "entry": [142, 148], "target": 196, "stop_loss": 118,
           "horizon": "intraday",
           "report_url": "...",
           "status": "open" }
       ]
     }

# normalize -> one record per call_id; an exit event on RA-48217
# updates status/exit_price in place rather than inserting a duplicate.
def upsert(call):
    row = store.get(call["call_id"]) or new_row(call["call_id"])
    row.update(map_fields(call))     # segment, levels, horizon, status
    if call["status"] == "closed":
        row.exit_price = call.get("exit_price")
    store.put(row)

Token lifetime is short, so the client refreshes ahead of expiry; the real-time P&L surface used by Scalper Mode runs over a persistent connection that needs reconnect handling, which we build in rather than leave to fail quietly.

What lands at the end

• An OpenAPI specification covering the auth exchange, the advisory feed, portfolio and order endpoints as mapped for this app.
• A protocol and auth-flow report: the token chain, refresh timing, and the persistent connection behind live P&L.
• Runnable source (Python or Node.js) for the key endpoints — session, advisory calls, holdings, alerts — with the normalization shown above.
• Automated tests against recorded fixtures so a field change surfaces as a failing test, not silent drift.
• Interface documentation: each object type, how recommendations and orders relate, and the entitlement gating by plan tier.
• Compliance and data-retention notes scoped to SEBI's research-analyst record rules and consent handling.

Consent and the SEBI side

Univest's research arm — Uniresearch India Pvt Ltd, a SEBI-registered research analyst (registration INH000013776 as stated in the app's own listing) — sits under the SEBI (Research Analysts) Regulations, 2014. SEBI amended those rules in December 2024 and published guidelines in January 2025 that require KYC of fee-paying clients and retention of client-interaction records for at least five years. Any integration touching advisory data is therefore built data-minimized and logged, with consent records kept and an NDA in place where the work involves a live account.

On the holdings side, the RBI Account Aggregator framework is a consent-first network: nothing is shared without the user's explicit, scoped, revocable consent, and the consent carries an expiry. We design the sync around that consent window so it renews on time instead of lapsing mid-run, and we scope every pull to the fields the consent actually grants.

Things we plan for in this build

• The advisory feed and the integrated broker are separate SEBI-registered functions, so we model recommendations and orders as distinct object types and join them only where a fill cites the call that prompted it — conflating them would corrupt both reconciliation and signal accuracy.
• Alerts fan out across push, WhatsApp and Telegram. We dedupe across channels and key on the call id so the same exit signal is never ingested twice.
• Scalper Mode's real-time P&L runs over a persistent stream; we handle reconnect and back the sync onto the short session-token lifetime so it does not silently drop mid-session.
• Advisory content is gated by subscription tier. We scope extraction to the consenting account's actual entitlements rather than assuming full access.
• The portfolio tracker's Buy/Sell/Hold rating is derived, not a raw holding field — we capture it as a separate attribute so a rating change does not look like a position change.

Working with us

Source-code delivery starts at $300, billed only after we hand over the build and you have run it against your own account. You get the runnable source, the OpenAPI spec, the tests and the interface docs, and you pay once you are satisfied it works. The alternative is the pay-per-call hosted API: we run the integration as endpoints you call, with no upfront fee — you pay only for the calls you make. Either way the cycle is one to two weeks. Tell us the app and what you want out of its data; we handle access, onboarding and the compliance paperwork with you. Start the conversation at our contact page.

Last checked 2026-06-24.

Interface evidence

Public store screenshots, used to confirm which surfaces the app exposes. Click to enlarge.

Sources and how this was put together

The mapping draws on the app's Play Store listing and univest.in for its feature set and SEBI registrations, SEBI's January 2025 research-analyst guidelines for the record-keeping rules, and the Government of India / RBI Account Aggregator material for the securities-data route. Checked June 2026.

• Univest on Google Play (com.univest.capp)
• SEBI — Guidelines for Research Analysts, January 2025
• Account Aggregator Framework — Dept. of Financial Services, Govt. of India
• PIB — four years of the Account Aggregator ecosystem

OpenBanking Studio · integration engineering notes, June 2026.

Similar apps in the same data space

These come up alongside Univest in Indian stock-research and investing. Each holds related data a unified integration could touch; listed for context, not ranked.

• Smallcase — curated stock baskets with SEBI-registered managers publishing buy/sell/hold actions; holds per-basket allocations and rebalance history.
• Tickertape — stock and mutual fund analytics with screeners and report cards; holds watchlists and saved screens.
• Trendlyne — research and screener data with analyst targets and alerts.
• Screener.in — fundamental data and custom queries over listed companies.
• Groww — broking and mutual fund platform holding orders, holdings and SIP records.
• Zerodha Kite — broker app with order book, positions and demat holdings.
• StockEdge — research analytics with scans, watchlists and study material.
• JARVIS Invest — SEBI-registered ML-driven recommendations and managed portfolios.
• Trade Brains Portal — fundamental data and educational tooling across NSE/BSE stocks.

Questions an integrator tends to ask

Can Univest holdings reconcile against the Account Aggregator network, or only through the app session?

Securities holdings tied to Univest's broking entity can move through the RBI Account Aggregator network where the depository participant is live as a financial information provider, which gives a clean, consent-backed feed for demat positions. The advisory layer — analyst calls, ratings, plan state — does not travel over AA, so we read that from the authorized app session. Most builds use both.

How are Univest's analyst recommendations structured when we extract them?

Each recommendation comes back as an object keyed by an internal call id: instrument and segment (equity, F&O, commodity), entry band, target, stop-loss, time horizon, and a link to the supporting report. We normalize that into one schema so an exit update on an existing call updates the same record rather than creating a duplicate.

Does the integration keep the advisory feed separate from the integrated broker's order data?

Yes. Univest carries distinct SEBI registrations for research analysis and for broking (per univest.in), and those are two different state machines — a recommendation is advice, an order is an execution. We model them as separate object types and link them only where a fill references the call that triggered it.

Which regulator covers Univest's research data, and what record-keeping comes with it?

Univest's research arm operates as a SEBI-registered research analyst. SEBI's January 2025 guidelines require KYC of fee-paying clients and retention of client interaction records for at least five years, so any integration touching advisory data is built data-minimized, logged, and scoped to consented fields.