Watchlists, screens and alert state inside a Deepvue account

A Deepvue account carries up to 1,500 symbols per watchlist (per the platform's watchlist docs), screener configurations built across a filter library Deepvue publicly cites as 1,490 filterable fields with 568 streaming live, plus an alerts table and a server-side AI Terminal thread — all of which sync across browser, iOS and Android on the same login. That is dense per-user state, not a thin client over a public feed. It is also the part of the product an integrator actually wants: the user's own lists, screens and alert rules in a form that can move into a downstream tool.

The brief below maps that state to specific reach paths, names the licensing edge cases that matter on US market data, and describes what we hand over.

What lives inside a Deepvue account

The interesting surfaces, mapped from what Deepvue itself documents:

Routes that actually work here

1 — User-consented account interface integration

The reliable path. The member logs in once during onboarding (or grants us a scoped session under their authorization), and we drive the same account-sync surface the iOS and Android clients use. That surface returns lists, sections, screens, alert rules, and AI threads as structured payloads. It moves with the product when Deepvue ships features, which they do often.

2 — Protocol analysis under the member's authorization

Where the surface has rougher edges — paginated screens, large universes, the AI Terminal's streaming responses — we run instrumented sessions against the mobile and web clients to capture the request shape, the auth chain (session cookie, sync token, client headers) and the back-pressure behaviour. Result: an OpenAPI spec we can stand behind and test against.

3 — Native export, as a fallback

The screener lets the member add selected rows directly to a watchlist or copy them via the in-app actions. That's useful for one-shot lifts but it does not carry the configuration, the alert rules, or the AI threads, so it is not a substitute for the integration — only a fallback when consent is unavailable for a specific surface.

In practice route 1 carries most of the integration, with route 2 reserved for the surfaces that route 1 cannot reach cleanly — long-tail screen pagination, AI Terminal streaming, the alerts firing log. Route 3 is documented for the member's own use, not a delivery path we ship.

Sketching the watchlist sync

Illustrative shape only — the precise field names, header set and cursor format are pinned during the build with the consenting member's session in front of us.

# Pull the watchlist tree on the consent path
POST /v1/sync/watchlists/pull
Cookie: dv_session=<session>
X-Client: dv-sync/<build>
Content-Type: application/json

{ "cursor": "wl:0", "include": ["lists","sections","color_tags"] }

# Response (truncated, fields confirmed during the build)
{
  "lists": [
    {
      "id": "wl_18acbb",
      "name": "Stage-2 breakouts",
      "kind": "user",
      "sections": [
        { "label": "Top of base",
          "symbols": [
            { "t": "NVDA", "added": "2026-05-12T13:41:09Z", "tag": "watch" },
            { "t": "AVGO", "added": "2026-05-14T10:02:55Z" }
          ]
        }
      ],
      "updated_at": "2026-05-23T17:12:04Z"
    }
  ],
  "cursor": "wl:18ad00"
}

The screener pull is a different shape — a filter document plus an optional materialised result set — and the alerts endpoint is its own surface again, including the firing history. The build covers all three.

The handoff

What ends up in the integrator's repo when the work lands:

• An OpenAPI 3.1 spec covering the watchlist tree, screener config / run, alert rules / events, and the AI Terminal thread surface (where in scope).
• A protocol and auth-flow note: the session and refresh chain, header set, cursor and pagination behaviour, observed rate behaviour, and the failure modes worth catching.
• Runnable client source — Python by default, Node.js on request — with the watchlist and screener flows wired end to end and a thin abstraction over the auth chain.
• An automated test suite that hits a consenting test account and verifies the round-trip shape rather than mocking it; the tests are the regression detector when Deepvue ships changes.
• Interface documentation written for an engineer who has never opened the app: what each surface returns, where the cursors restart, what to expect on a large watchlist.
• A short compliance and retention note covering what we pulled, the consent record, and what should not cross into the integrator's storage (raw real-time quotes being the headline example).

What the build has to get right

• Watchlist size and sections. Deepvue's own docs cite up to 1,500 symbols per list with named sections and combo views. We size the pull and the local model around that ceiling, and we represent sections as first-class entities so a downstream view of the same list does not collapse the structure the member built.
• Screener universe coupling. A Deepvue screen can take another watchlist as its universe. That means a working sync has to know the dependency graph between lists and screens, or a screen on the integrator side will silently point at a stale or wrong universe. The build keeps that graph explicit.
• Auth chain across browser, iOS and Android. The same account works on three clients and they share state. We pin the auth and refresh chain against one of those flows during onboarding so the integration does not behave one way against a fresh session and another against a long-lived one.
• Front-end drift. This is an actively shipping product. The test suite probes the live shape on a schedule, so a Deepvue UI or sync-surface change shows up as a failing assertion within a release of theirs, not as silent data loss two weeks later.
• AI Terminal scope. Threads are pullable on consent but often hold trading rationale the member did not write expecting it to leave the app. We treat that domain as opt-in inside the larger scope and surface a clean toggle for it.

Where the licensing actually bites

This is the regulatory clamp on the work and it sits in a specific place. The member's own account data — their lists, their screens, their alerts, their AI threads — is theirs to authorise an export of, and consent plus US privacy law (CCPA/CPRA in California, the broader patchwork elsewhere) is the dependable basis. The integration logs the consent, scopes the pull, and minimises what crosses the boundary.

The real-time US quote feed that flows through the screener is a different question. Those quotes ride the CTA and UTP SIPs and the SEC's Market Data Infrastructure rule framework, with redistribution restricted by the exchanges' licensing terms. The integration pulls account state and Deepvue's derived ratings; it does not redistribute raw last-trade or quote data, and downstream code is expected to source its own market-data feed under its own license. That separation is written into the deliverables and we say so to the member at consent time.

Interface evidence

Screens from the current build of the Deepvue mobile client, illustrating the surfaces the integration targets.

Sources and method

We read Deepvue's own knowledge base and product pages for the watchlist limits, the screener filter library and the AI Terminal scope; checked the iOS App Store listing for the package identity; and reviewed the SEC's Market Data Infrastructure framework so the licensing line in this brief is anchored, not asserted. Specific deep links:

• Deepvue — Meet the Screener (filter counts, streaming fields)
• Deepvue — Watchlists and color lists (1,500-symbol limit, sections, combo views)
• App Store — Deepvue (id 6470937111)
• SEC — Market Data Infrastructure rule

Notes by the OpenBanking Studio integration desk, 2026-05-24.

Where Deepvue sits among the screener crowd

These are real same-category tools. Listed so the integration scope can be sized against an integrator's wider stack, not as rankings.

• TradingView — browser-first charting and screening with a large community-script layer; holds per-user watchlists, layouts and Pine scripts.
• MarketSurge — IBD's CANSLIM-anchored research suite; holds per-user lists and saved screens against a curated dataset.
• TC2000 — desktop scanner with EasyScan and integrated brokerage; per-user scans, alert lists and watchlists.
• Finviz — fast web screener with portfolio and elite tiers; per-user portfolios, screener presets and alerts on the paid plan.
• TrendSpider — automated technical analysis with smart-checklist scanning; per-user setups and saved scans.
• Stock Rover — fundamentals-led research with portfolio and watchlist surfaces; per-user lists, screens and history.
• Trade Ideas — momentum scanning with the Holly ML engine; per-user channels, alerts and OddsMaker setups.
• Koyfin — macro and fundamentals dashboards; per-user dashboards and watchlists.
• ChartMill — global multi-exchange screener; per-user lists and saved filter sets.
• Seeking Alpha — research feed and ratings layer; per-user portfolios and alert rules.

Questions specific to Deepvue builds

Can the screener configuration be round-tripped, not just the symbols it produced?

Yes. The screener carries the filter set, the universe (which can include other watchlists as inputs) and the saved layout, not only the resulting tickers. With the user's consent we model both surfaces: a snapshot of the symbol list at the moment of the pull, and the configuration document itself, so a downstream system can re-run the same screen against its own data later.

Where does the AI Terminal's chat history live, and is it pullable with consent?

Threads are tied to the account and sync across browser and the mobile clients, so they sit server-side rather than on the device. They are pullable on the consent path. We usually treat them as opt-in inside a larger integration because they often contain free-form trading notes the user may not want re-flowed into a downstream tool.

Real-time US quotes pass through Deepvue. Can we redistribute them in the integration?

No, and that is a US exchange-licensing question rather than a Deepvue one. Quotes carried by the CTA and UTP SIPs ride redistribution rules set by the exchanges and the SEC's Market Data Infrastructure framework. The integration pulls account state and derived rankings; downstream code sources its own market data feed under its own license.

What's the cleanest way to keep a downstream watchlist in sync as a Deepvue user edits theirs?

We model the sync around the same cursor the mobile clients use and add a periodic full reconciliation against the watchlist tree (lists, sections, color tags). That way a deletion or a re-sectioning on the Deepvue side does not silently drift away from the copy on the integrator's side.

A typical Deepvue build lands as a runnable Python client over the watchlist, screener and alerts surfaces, plus the OpenAPI spec and the protocol note, inside a one-to-two-week cycle. Source delivery starts at $300, paid after we hand it over and you have run it; alternatively the same integration is available as a pay-per-call hosted API with no upfront fee, so you only pay for traffic. Either path starts with a short scope note — tell us what you need from a Deepvue account and we route from there.