Syncing Investidor10's B3-imported holdings and proventos ledger into your own systems

The interesting data in Investidor10 is not entered by hand — it arrives from B3. According to the app's own support material, the PRO tier pulls a member's positions straight from the exchange's investor channel, so the consolidated portfolio reflects what settled at the depositary rather than what someone typed in. That makes the data dependable and also gives the integration its rhythm: B3 can take up to three business days to propagate a new position, so anything pulling this data has to be built around confirmation, not immediacy.

For a team that wants Investidor10's view of holdings, average price and dividend flow in their own stack, two authorized paths exist side by side. Where the investor consents, the Open Investment phase of Open Finance Brasil carries the underlying positions under Banco Central supervision. Where the target is specifically how Investidor10 consolidates and presents that portfolio, we map the app's authenticated interface under the client's authorization. The sections below name the surfaces, then show what we hand over.

What the app actually holds

Investidor10 spans several Brazilian instrument types — Ações, Fundos Imobiliários, BDRs, ETFs and more — and keeps both current state and history for each. The surfaces worth integrating:

Routes to the data

Open Investment consent (regulated)

The Open Investment phase of Open Finance Brasil was built precisely for this: letting a customer move investment information — variable income, fixed income banking and credit, Treasury securities, funds — between participating institutions with their explicit consent. The flow is OAuth Authorization Code with PKCE, with tokens minted by the ecosystem and consent recorded under Banco Central rules. Reachable: the regulated, standardized position data. Effort is moderate and the durability is high, because the schema and the consent contract are defined by the regulator rather than by an app build. We arrange the participant routing and the sandbox onboarding with you as part of the project.

Authorized interface integration

When the goal is Investidor10's own consolidated view — the way it merges B3 data with manual entries, its average-price math, the proventos split — we analyze the app's authenticated traffic under your authorization and rebuild the request and token chain as a clean client. Reachable: everything the app itself renders for the account. Effort is higher and the surface can shift with app releases, so we ship it with a test suite that flags drift early.

B3 investor-channel authorization

Because the source of truth is B3's depositary, some engagements go to the exchange's investor-channel interfaces directly, which financial and non-financial institutions can contract under investor authorization. This is the cleanest path when the client wants positions independent of any one app's presentation layer.

Native export fallback

Where a one-off pull is all that's needed, the in-app and web exports cover a snapshot of positions and income without standing infrastructure. Useful for a migration, weak for an ongoing feed.

For most teams we lead with consented Open Investment data for its stability, then use the app interface to recover whatever the regulated schema does not carry — the contribution-adjusted growth curve and the app's own proventos calendar being the usual gaps.

What ships to you

The headline deliverable is code that runs, not a document set:

• Runnable client source in Python and Node.js for the holdings, average-price and proventos surfaces, with retry and token-refresh handling already wired in.
• A webhook handler that turns "B3 confirmed a new position" or "a provento was paid" into a signed event your services can subscribe to, with replay support so a delayed B3 confirmation is not lost.
• An automated test harness that asserts the shape of each surface, so a change in the upstream interface shows up as a failing assertion before it reaches your pipeline.
• A sync design that states plainly which data is realtime-ish and which rides B3's multi-day confirmation, so batch and incremental paths are not mixed up.
• Secondary: an OpenAPI description of the rebuilt endpoints, a protocol and auth-flow report (the OAuth/PKCE or cookie-token chain as it actually behaves here), interface documentation, and data-retention guidance.

A surface, concretely

The proventos calendar is the surface clients ask about most, because it carries the paid-versus-scheduled distinction that drives income planning. An illustrative request and the event we emit when a distribution lands (field names confirmed against the live interface during the build):

GET /portfolio/{portfolioId}/proventos?status=all&from=2026-01-01
Authorization: Bearer <access_token>        # OAuth code+PKCE, refreshed before expiry

200 OK
{
  "portfolioId": "p_8841",
  "items": [
    { "ticker": "ITUB4", "type": "DIVIDENDO",
      "status": "PAID",      "dataCom": "2026-03-14",
      "paymentDate": "2026-04-02", "perShare": 0.21, "currency": "BRL" },
    { "ticker": "MXRF11", "type": "RENDIMENTO",
      "status": "SCHEDULED", "dataCom": "2026-06-28",
      "paymentDate": "2026-07-08", "perShare": 0.10, "currency": "BRL" }
  ]
}

# emitted to subscribers when status flips PAID:
POST /your-webhook
{ "event": "provento.paid", "ticker": "ITUB4",
  "portfolioId": "p_8841", "amount": 0.21, "paidOn": "2026-04-02" }

For pre-November-2019 positions the cost-basis fields carry a flag, because B3 only holds history back to October 2019 and those lots are parametrized to a 01/11/2019 acquisition date — the integration passes that flag through rather than presenting a synthetic date as real.

Normalized shape

However the data is reached, it lands in one neutral schema so downstream code does not care about the source:

Holding   { ticker, assetClass, quantity, avgPrice, avgPriceSynthetic:bool }
Provento  { ticker, kind, status:[PAID|SCHEDULED], dataCom, paymentDate, perShare }
Snapshot  { takenAt, source:[open_investment|app_interface|b3_channel], holdings[] }

Consent and the rules that apply

This is Brazilian financial data, so the framework is Open Finance Brasil under Banco Central do Brasil, with the Open Investment phase covering exactly the asset types Investidor10 tracks. Consent is explicit, scoped to named data clusters, time-boxed, and revocable by the investor at any point; the integration refreshes authorization ahead of expiry so a long-running feed does not quietly stop. On the personal-data side, LGPD governs what we may store and for how long, which is why the build is data-minimized — positions and income only, no scraping of unrelated profile fields — and logged. Where the engagement touches an account directly, it runs under NDA against a consenting account or a sandbox arranged with you.

Engineering notes worth stating up front

Two things about this app shape the build, and we handle both rather than passing them to you as caveats:

• B3's confirmation lag is designed in, not fought. New positions can take up to three business days to appear after a trade settles. We model that window explicitly, reconciling positions as B3 confirms them and only emitting a change event on actual movement, so the feed is correct rather than merely fast.
• The pre-2019 history boundary is carried through. Because B3's history starts in October 2019, older lots import quantity-only with a parametrized acquisition date. We surface that as an explicit flag on average price so any tax or profitability logic downstream treats it correctly.
• The B3 import is PRO-gated. Auto-import is an Investidor10 PRO feature, so we scope the integration to the account tier in play and design around what the chosen tier actually exposes.

Working together

A typical first drop here is the proventos and holdings client plus its tests, inside a one-to-two-week cycle. You can take the source-code delivery: we build the runnable integration and its documentation for your app and requirements, from $300, paid after delivery once it works for you. If you would rather not run anything, use the hosted route and call our endpoints, paying per call with nothing upfront. Either way you give us the target — Investidor10 here — and what you need from its data; access, consent routing and the compliance paperwork are arranged with you as we go. Tell us what you need on the contact page and we will scope it.

Interface screens

The app's own screens, as published on its store listing — useful for seeing which surfaces carry the structured data named above.

Similar apps in the same data space

Brazil has a crowded field of portfolio consolidators, and integrators often want several mapped to one schema. Neutral notes on the neighbours:

• Status Invest — fundamentals and portfolio tracking; holds per-user positions alongside a deep indicator database.
• Kinvo — consolidates investments across banks and brokers, with wealth-evolution and profitability views.
• Gorila — multi-class portfolio tracking with broker connection and come-cotas handling, fed from official sources.
• Real Valor — dividend-focused tracking that imports from the investor's electronic channel, web and app.
• TradeMap — multibroker aggregation with real-time quotes and dividend notifications across BR and US assets.
• Meus Dividendos — income-centric tracker built around dividend receipts and projections.
• Toro — broker app with its own portfolio and order data behind an authenticated account.

Questions integrators ask

How fresh is the portfolio once a sync is running, given B3's settlement lag?

B3's own propagation can take up to three business days for newly traded positions to land in the importer, per the Investidor10 support pages. We build the pipeline to treat that window as expected: positions reconcile as B3 confirms them, and a push event fires when a holding or a provento actually changes, rather than the integration assuming everything is same-day.

Can the integration separate proventos already received from scheduled ones?

Yes. The proventos ledger distinguishes income already paid from future distributions with their data-com and payment dates, and we surface that split in the normalized schema so an income-forecasting tool can read paid-versus-pending without re-deriving it.

Does this ride Open Finance Brasil, or the app's own interface?

Both are on the table. Where the investor consents, the Open Investment phase of Open Finance Brasil carries variable income, fixed income, funds and Treasury positions under Banco Central supervision. Where the goal is the way Investidor10 itself presents the consolidated portfolio, we map the app's own authenticated interface under the client's authorization. We usually recommend leading with consented Open Investment data and using the app interface to fill what the regulated schema does not expose.

How do you handle cost basis for assets bought before late 2019?

B3 only carries history back to October 2019, so for assets acquired before 01/11/2019 the quantity imports but the original purchase date does not, and those positions are parametrized to an 01/11/2019 acquisition date. We flag that synthetic date in the average-price output so downstream tax or profitability logic does not treat it as a real trade date.

Sources and review

Written from the app's Google Play and App Store listings, its support pages describing the B3 import and its limits, the Open Finance Brasil developer material on Open Investment, and B3's own investor-channel API page, all opened on 2026-06-07. Primary references: Investidor10 support, B3 investor-channel APIs, Open Finance Brasil developer area, and Open Investment overview.

OpenFinance Lab · interface engineering notes, 2026-06-07.