Getting positions, strategies and balances out of Openvest

Every dollar in an Openvest account is custodied and cleared at Interactive Brokers LLC, per the platform's own disclosures, and that one fact decides how you read the account in code. The listed holdings, the cash, and the fills sit inside an IBKR account structure. The part that makes Openvest itself — the managed strategy, the recurring auto-invest, the alternatives sleeve, the plan tier — lives in Openvest's own backend. A real integration has to read both and stitch them into a single feed. This page maps those surfaces, the authorized way to reach each one, and the client we hand back.

The short version: most of the money lives at IBKR and is reachable through a documented API once the member consents; the strategy and alternatives context lives only inside Openvest and is reached by authorized analysis of the app's own traffic. We pull both into one normalized object so downstream code never has to ask which backend answered.

The records behind an Openvest account

These are the surfaces a member sees in the app, mapped to where the data actually originates and what an integrator tends to do with each.

Three authorized paths to the holdings data

Two of these carry the real weight; the third is a cross-check.

User-consented access to the IBKR custody layer

Because custody and clearing sit at Interactive Brokers, the listed holdings, cash, statements and fills are reachable through IBKR's documented Web API once the account holder consents. IBKR approves third-party software through an OAuth flow and a multi-week onboarding and compliance review (per IBKR Campus); we run that with you rather than hand it over as homework. This is the durable spine for the numbers.

Authorized interface integration of the Openvest layer

The parts that are Openvest's own do not live at IBKR — strategy targets and drift, the auto-invest schedule, the alternatives sleeve, plan tier and alerts. We reach those through documented analysis of the app's authenticated traffic, under your authorization, and re-check the surface as part of ongoing upkeep so an app release does not quietly change a field on you.

Member-facing export as a fallback

Where Openvest or IBKR exposes a statement or member-facing export, we use it as a fallback and a reconciliation check against the live pulls. It is slower and coarser, but it is good ground truth.

Neither the IBKR feed nor the app-layer analysis is a whole account on its own: the first misses the strategy and alternatives context, the second lacks authoritative settled balances. We build both and reconcile them, with the export path kept as a check. That combination is what we would actually recommend here.

What you get back: code, clients, tests

The headline deliverable is runnable code, not a binder.

• Python and Node.js client libraries (Go on request) that authenticate to both surfaces, pull every domain in the table above, and emit one normalized account object.
• Handlers for new fills and strategy-drift events, run as scheduled polls or as push where a surface supports it.
• An automated test suite with fixtures captured from a consenting account or sandbox, so a changed field shows up as a red test before it reaches release.
• An auth-flow report documenting the OAuth token chain at IBKR and the session chain for the Openvest app layer.
• An OpenAPI description of the normalized endpoints, with interface documentation written for the engineer who maintains it.
• Data-retention and consent-logging guidance written against Regulation S-P.

Reading positions and the strategy mix, step by step

A sketch of the client we hand over. It authenticates to both surfaces, pulls each domain, and normalizes. Token refresh fires on the auth boundary, not a fixed timer. Field names here are illustrative and pinned against a consenting account during the build.

# openvest_client — assemble one account view from two backends
from openvest_client import Openvest, AuthError

ov = Openvest.from_consent(
    ibkr_oauth=ibkr_token,        # account-holder consented, IBKR-issued
    app_session=openvest_session, # Openvest app-layer session
)

try:
    acct      = ov.account()       # plan tier, account type (taxable / IRA)
    positions = ov.positions()     # listed holdings, custodied at IBKR
    strategy  = ov.strategy()      # model id, target weights, drift
    alts      = ov.alternatives()  # PE / real estate / private credit sleeve
    schedule  = ov.recurring()     # auto-invest cadence + next run
except AuthError:
    ov.refresh()                   # re-auth on the boundary, caller retries
    raise

view = ov.normalize(positions, strategy, alts, schedule, acct)
# each holding carries view.holdings[i].source in {"ibkr", "openvest"}

The normalized shape it returns

One object, every backend folded in, with the originating surface tagged so reconciliation stays honest.

{
  "account": { "id": "ov_…", "type": "individual", "plan": "retail-5usd" },
  "as_of": "2026-06-08T00:00:00Z",
  "holding": {
    "symbol": "VTI",
    "source": "ibkr",
    "quantity": 12.5,
    "market_value_usd": 3187.50,
    "strategy_id": "ov-core-growth",
    "target_weight": 0.18
  },
  "alternative": {
    "sleeve": "private-credit",
    "source": "openvest",
    "valuation_cadence": "monthly",
    "last_nav_usd": 5000.00
  }
}

Consent and the SEC-adviser rulebook

Openvest is the consumer brand for Openvest Access LLC, an SEC-registered investment adviser (CRD 328152, per adviserinfo.sec.gov). That shapes the data work in two concrete ways. Customer records fall under the SEC's Regulation S-P, whose 2024 amendments add breach-response and notification duties for advisers, phased into effect from late 2025 (per the SEC's Federal Register notice); so any integration logs access, copies the minimum it needs, and keeps consent records. The dependable legal basis for reading an account is the member's own authorization — the same consent Interactive Brokers requires before it approves third-party access to a funded account. Where US consumer financial-data rights are heading, the CFPB's Personal Financial Data Rights rule under Section 1033, is still unsettled: that rule is back in agency reconsideration and not in force, so we treat it as a direction of travel, not a present-day obligation, and build on consent today.

Wrinkles we plan around on this build

Two custody surfaces, one account. Cash, positions and fills are authoritative at IBKR, while strategy targets, the auto-invest schedule, the alternatives sleeve and the plan tier are authoritative at Openvest. We build the join and handle the timing gap where a settled IBKR position lags a pending Openvest auto-invest, so a deposit in flight is not counted twice.

Alternatives do not tick. The private-equity, real-estate and private-credit positions revalue on a slow cadence, so we model them as NAV-style valuation events separate from listed-security marks; a stale alternative valuation stays labelled stale rather than masquerading as a live price.

Plan tier changes what exists. Openvest prices a retail account at a flat monthly fee and tiers its IRA and 401(k) accounts by balance (per openvest.co), and account type governs which features and tax treatment apply. We scope the sync per account type, so a member holding both a taxable and a retirement account is read correctly. The IBKR third-party path uses OAuth and a staged onboarding review; we run that with you during onboarding and design the token refresh around it.

Screens we mapped against

Store screenshots used while sketching the surfaces above.

Neighbors in the managed-investing space

Same broad category, different mixes of automation, fee model and asset coverage. Naming them widens the picture for anyone building one account view across several apps.

• Wealthfront — automated portfolios across stocks, bonds and real-estate ETFs, with an annual percentage management fee.
• Betterment — goal-based automated investing with large retail membership and crypto portfolios alongside the core models.
• Fidelity Go — a low-cost robo built on Fidelity's own funds, with advisor access at higher balances.
• Schwab Intelligent Portfolios — automated ETF portfolios tied to a brokerage account and a cash allocation.
• SoFi Automated Investing — automated portfolios with access to fiduciary advisors and a low entry minimum.
• Titan — actively managed strategies including alternatives, positioned close to Openvest's pitch.
• Yieldstreet — private-market and alternative-asset deals across credit, real estate and other sleeves.
• Fundrise — retail access to private real-estate and venture funds with periodic NAV valuation.
• M1 Finance — self-directed automated portfolios ("pies") with recurring deposits and rebalancing.

Sources and the desk behind this

Checked on 2026-06-08 against the app's store listing, its own site, the SEC adviser register and Interactive Brokers' developer material. Primary references:

• Openvest on Google Play — product description, fees, custody and security claims.
• SEC IAPD — Openvest, CRD 328152 — adviser registration.
• IBKR Campus — third-party connections — OAuth and the onboarding review for third-party access.
• Regulation S-P amendments — adviser privacy and safeguarding duties.

Engineering notes compiled by OpenFinance Lab on 2026-06-08.

Questions integrators ask about Openvest

Which language clients do you ship for pulling an Openvest account?

Python and Node.js by default, with Go on request. Each one authenticates against both surfaces, pulls positions, cash, strategy targets, the alternatives sleeve and recurring schedules, and returns them in one normalized object so your code does not care which backend answered.

How do you reconcile the Interactive Brokers side with Openvest's own strategy layer?

We build the join. Listed holdings, cash and fills come from the IBKR account structure; strategy targets, drift, auto-invest schedules and plan tier come from Openvest's backend. The client tags each holding with the surface it came from and lines up settled IBKR positions against pending Openvest deposits, so a mid-flight auto-invest is not double counted.

Are the private equity and real estate positions readable the same way as listed holdings?

Not quite. The alternatives sleeve revalues on a slow cadence rather than tick by tick, so we model those as NAV-style valuation events kept separate from listed-security marks. A stale alternative valuation stays flagged as stale instead of passing for a live price.

Does reading an Openvest account require the member's own login and consent?

Yes. The dependable basis is the account holder's own authorization, which also matches how Interactive Brokers approves third-party access to a funded account. We arrange that access and the related compliance steps with you during onboarding, and keep consent and access records under the SEC's Regulation S-P safeguarding expectations.

A first usable Openvest client — positions, cash and strategy mix landing in one normalized object — typically takes one to two weeks. Take it as source you own outright, billed from $300 and paid only after it is delivered and you have watched it run; or call our hosted endpoints instead and pay per call with nothing up front. Either way, you give us two things: the app name and what you want out of its data. Access, the IBKR third-party onboarding and the compliance paperwork are arranged with you from there. Start the conversation on our contact page.