Getting bank and card data out of Despezzas

Despezzas links to more than 30 Brazilian banks and reads their accounts and cards automatically — its own marketing leads with the line "Controle Financeiro Pessoal com Open Finance," and the home page names Nubank, Itaú and Bradesco among the connections. That single sentence settles the integration question before it is asked. The data a partner would want from Despezzas — a user's balances, posted transactions, card bills and budget categories — already flows in through Brazil's regulated Open Finance rails. So the cleanest way to reach it is the same way Despezzas itself does: a consent-based Account Information Services connection, granted by the account holder.

What follows maps the data Despezzas actually carries, the authorized way to read it, and the source code we hand over at the end. The recommendation in short: build on the regulated AIS consent flow, because that is the channel Despezzas was designed around, and keep documented protocol analysis of the app's own traffic in reserve for fields the regulated APIs do not surface.

What Despezzas actually holds

These domains come from the app's published feature list and store descriptions. Each maps to a real screen a user already sees, which is what makes them worth integrating.

Reaching the data

Two routes carry almost everything; a third is a fallback we rarely need to lean on.

Regulated AIS consent (Open Finance Brasil)

This is the channel Despezzas itself rides. A user authorises an account-information data recipient and the bank then shares accounts, balances, transactions and card data over Brazil's FAPI-secured APIs. Reach is wide and the durability is strong — it is law-backed infrastructure, not a private endpoint that breaks on the next release. The cost is setup: a data-recipient onboarding and FAPI/OIDC conformance. We arrange that onboarding with you as part of the build, working against a sandbox or a consenting account so you are not stalled waiting on it.

Documented protocol analysis of the app's traffic

For anything the user sees inside Despezzas that the regulated feed does not expose cleanly — the app's own budget categories, goal progress, custom tags — we analyse the client's authenticated traffic under your authorization and reconstruct the request, the token handling and the response shape into a stable interface. Faster to reach the exact in-app fields; needs a re-validation pass when the app's front end changes, which we build into maintenance.

Native export

Where Despezzas offers a user-facing export, it works as a low-effort backstop for batch needs, though it is coarser than either live route. Useful for a one-off migration, not for a real-time sync.

For Despezzas specifically, the AIS consent flow is the right spine: the app's whole value proposition is built on it, the data is the same data, and it survives app updates. Protocol analysis sits alongside it to recover the handful of app-native fields the regulated APIs were never meant to carry.

What we build for this app

• OpenAPI specification covering a normalized model — accounts, transactions, cards, budgets, goals — so your side codes against one schema regardless of which underlying route fed a field.
• Consent & auth-flow report documenting the Open Finance Brasil FAPI flow as it applies here: the OAuth 2.0 + OIDC dance, the consent resource lifecycle, refresh-token handling tied to an AUTHORISED consent.
• Runnable source in Python or Node.js for the endpoints that matter — list accounts, page transactions, read card bills and due dates — with retry, paging and token-refresh handled.
• Automated tests against recorded fixtures plus a sandbox run, so the contract is verified, not assumed.
• Interface documentation and data-retention guidance written for an LGPD context, with consent and access logging baked in.

The shape of a request

Illustrative, not a copy of any private endpoint — this is the Open Finance Brasil account-data pattern the integration is built on, with field names confirmed against the published Consents and Accounts specs.

POST /open-banking/consents/v3/consents        # create a consent
Authorization: Bearer {client_credentials_token}
{
  "data": {
    "permissions": ["ACCOUNTS_READ","ACCOUNTS_BALANCES_READ",
                    "ACCOUNTS_TRANSACTIONS_READ","CREDIT_CARDS_ACCOUNTS_READ"],
    "expirationDateTime": "2026-12-04T00:00:00Z"
  }
}
# user authorises in their bank (FAPI redirect, OIDC) -> consent status AUTHORISED

GET /open-banking/accounts/v2/accounts          # then read with the user token
Authorization: Bearer {access_token_linked_to_consent}
x-fapi-interaction-id: 7c8f...

200 OK
{
  "data": [{ "accountId": "...", "type": "CONTA_DEPOSITO_A_VISTA",
             "currency": "BRL" }],
  "links": { "next": ".../accounts?page=2" },
  "meta":  { "totalRecords": 3 }
}

# error path we handle explicitly
401 -> token/consent expired  -> refresh against active consent, else re-prompt
429 -> rate limited           -> honour backoff, resume paging from links.next

Credit-card data follows the same pattern under its own resource path, which is why we model cards as a distinct entity and reconcile them back to one user view.

Consent, LGPD and how we operate

Open Finance Brasil is run by Banco Central do Brasil with the CMN; it launched in phases from 2021 and account and transaction data sharing sits in the customer-data phase. Two things govern any read: the user's explicit consent, scoped to named permissions with an expiry, and LGPD over the personal data itself. Consent is revocable at any moment, and the platform requires that access tokens only return data while their consent is AUTHORISED. We honour that by storing consent records, refreshing before expiry rather than after, requesting only the permission scopes a use case needs, and logging every access. NDAs where the engagement calls for one. The posture is authorized, documented, data-minimized access — that is simply how the studio works, not a hoop for you to clear.

Engineering notes specific to Despezzas

• Many banks, many consents. Because Despezzas spans 30+ institutions, a real user has several live consents at once, each with its own expiry. We track them per institution and renew each before it lapses, so the aggregate view never silently goes stale on one bank.
• Cards are not accounts. The app keeps card limits, bills and due dates as a separate surface, and the Open Finance model puts credit-card resources under different endpoints from deposit accounts. We build them as separate resources and stitch them back together, rather than forcing cards into an account shape.
• App-native fields need the second route. Budget limits, custom categories, tags and goal progress are computed inside Despezzas, not in the bank feed. We map those through documented protocol analysis and reconcile them against the regulated records, with a re-validation step wired into maintenance for when the client UI shifts.
• One model across web and mobile. Despezzas presents the same records on web, Android and iOS; we target the data layer so a single integration covers all three clients.

Where teams put this

• A lender or advisory product reading a consenting user's consolidated cashflow and card exposure to underwrite or coach, instead of asking for screenshots.
• An accounting or expense tool importing categorized transactions and due dates so a household's Despezzas budget flows into the books automatically.
• A migration that lifts a user's history and goals out of Despezzas into another planning app on request.

Working with us

You give us the target — Despezzas — and what you need pulled from it; we handle the route, the onboarding and the code. Delivery runs on a one-to-two-week cycle. From there the pricing is straightforward: source-code delivery starts at $300, where you receive the runnable API source, the spec, the tests and the docs, and you pay only after delivery once it works for you; or the pay-per-call hosted API, where we run the endpoints and you pay per call with nothing upfront. Tell us which fits and what you want from the data — start the conversation here.

Screens from the app

Pulled from the store listing — useful for seeing which surfaces map to which data domain above.

Apps in the same neighbourhood

Other Brazilian personal-finance apps that hold comparable data; named so you can scope a unified integration across a category, not to rank them.

• Mobills — broad expense tracker with automatic bank and card sync; one of the most complete in the market, holding the same transaction and card data.
• Organizze — simplicity-first budgeting, with SMS/notification import and a strong manual-entry base of transactions and categories.
• Guiabolso — built on automatic, secure bank and card connection, consolidating movements and categorizing spend.
• Minhas Economias — fully free manual expense control; ledger and category data without aggregation.
• Money Lover — multi-award budgeting app organizing spend into customizable categories.
• Monefy — quick income/expense capture with category visualisation through charts.
• Serasa — credit and finance app whose tracking features touch overlapping personal-finance data.
• Mobills Fin — the lighter AI-assisted entrant in the same expense-management family.

What was checked

Mapped against the app's own site and store listings and the Open Finance Brasil developer material in June 2026. Primary sources opened: despezzas.com.br, Banco Central do Brasil — Open Finance, Open Finance Brasil Consents API spec, and the App Store listing.

Mapping by the OpenBanking Studio integration desk — June 2026.

Questions integrators ask

Despezzas connects to dozens of banks through Open Finance — can that same path feed an integration?

Yes. Despezzas aggregates accounts and cards from more than 30 Brazilian institutions over Open Finance Brasil, as its own site describes. The same regulated AIS consent flow — a customer authorising an account-information data recipient — is the route we build against, so an integration reads the same balances, transactions and card data the app shows, under the user's own consent.

Who regulates pulling a Despezzas user's bank data, and how long does a consent last?

Open Finance Brasil is governed by Banco Central do Brasil and the CMN; LGPD covers the personal data. Consent is granted per data scope with an explicit expiry and can be revoked by the user at any time. We design the sync so each AUTHORISED consent is tracked and renewed before it lapses, and we keep consent and access logs.

Can credit-card limits and bill due dates come through separately from account transactions?

They can. Despezzas treats credit cards as their own surface — limits, current bills, payment reminders — distinct from bank-account movements. In the Open Finance data model card resources sit under credit-card endpoints separate from account endpoints, so we model them as separate resources and reconcile them back to a single user view.

Despezzas runs on web as well as mobile — does that change the integration?

The data is the same either way. Despezzas exposes the same account, card and budget records on its web app and its Android and iOS clients, so the integration targets the underlying data layer rather than a single client. Where the regulated AIS path does not reach a given field, documented protocol analysis of the app's own traffic, under your authorization, fills the gap.