Getting balances and trade history out of Bity, across its two backends

A Bity account is not one data source, it is two stitched behind a single login. The simple buy and sell path runs as a quote-and-confirm flow on the Biscoint REST surface at api.biscoint.io: you ask for an offer, you get a short-lived price aggregated from exchanges like Binance, Mercado Bitcoin and NovaDAX, and you confirm it. The PRO trading view that came over from Bitypreço — order book, charts, limit and stop orders — sits on a different trading backend. An integration that only reads one of those returns half a portfolio. This brief covers both, the Pix and Bix money movement around them, and the authorized way to reach the lot.

For most teams the spine is authorized REST integration under the account holder's own key, with the PRO interface captured through protocol analysis when order-book depth or working orders are in scope, and the CSV statement used to backfill history older than the recent-fills window. Below: the data, the routes, what we hand over, and the Brazilian rules that bound it.

What the account actually exposes

Domains below are mapped to where they originate inside Bity, not a generic exchange checklist.

Routes to that data

Authorized REST integration under the account key

The account holder generates an API key and secret on their own verified Bity/Biscoint account; we set that up with the client during onboarding. From there, balances, recent trades, and the offer/confirm flow at api.biscoint.io are reachable directly. Effort is low to moderate, durability is high — the surface is versioned and there are documented client wrappers in Node.js and Python we validate the signing chain against. This is the recommended spine for the live crypto account.

Protocol analysis of the Bitypreço PRO interface

Order book, live depth, limit and stop orders are not in the REST quote path; they live on the separate PRO trading backend. We capture and document that interface — session, auth chain, message shapes — from a consenting account. Effort is moderate, durability is medium because session and auth handling on that backend can shift; we account for that with a re-validation step in maintenance. Added when working orders or book depth are in scope.

Native CSV statement

The platform's extrato export gives a full historical operations file, the route the Brazilian crypto-tax tooling already uses for Bity. Effort is low. It is a periodic, manual surface, so we treat it as a backfill and reconciliation path rather than a live feed.

Open Finance Brasil consented sharing — BRL leg only

The regulated banking and Pix side of a Bity account can be reached through Open Finance Brasil consented data sharing (registration and transactional data) where Bity participates as an institution. This covers the fiat and payment leg, not the crypto ledger, which stays on the routes above.

What lands in your repo

Each item is tied to a surface above, not a generic deliverable list:

• An OpenAPI description of the balance, trades and offer/confirm surface as we integrate it, with the Pix/Bix and card records modelled alongside.
• A protocol and auth-flow report: the signed-request chain for api.biscoint.io and the separate session/auth chain for the Bitypreço PRO backend, written so an engineer can re-derive both.
• Runnable source in Python and Node.js for a balance pull, paginated trade history, and the quote-then-confirm cycle, structured around the published per-minute limits.
• An automated test suite that is rate-limit aware (the private endpoints are capped per minute) and exercises offer expiry and re-quote.
• A CSV normalizer that maps the extrato export into the same schema as the REST path, so backfill and live data reconcile.
• Interface documentation plus data-retention and consent guidance under the Brazilian virtual-asset framework.

A quote call, end to end

The shape of the simple-path integration: a signed private request, an offer, a confirm inside the validity window, then a balance and trade read. Field names follow the documented client wrappers; the exact signing string is confirmed during the build against the documented wrapper and a test account.

# Authorized integration against the holder's own Bity/Biscoint key
# Base: https://api.biscoint.io  — private calls are HMAC-signed
# (signing payload validated during the build against the documented wrapper)

POST /v1/offer
  body: { amount: "200.00", isQuote: true, op: "buy", base: "BTC" }
  -> 200 { offerId, base, quote, efPrice, isQuote, expiresAt }

# offers are short-lived best-price quotes aggregated across venues;
# confirm inside expiresAt or the offerId is dead and must be re-quoted
POST /v1/offer/confirm
  body: { offerId }
  -> 200 { confirmedAt, baseAmount, quoteAmount, efPrice }
  -> 4xx OFFER_EXPIRED        # re-quote, do not retry the same offerId
  -> 429 RATE_LIMIT           # back off; offer window ~24/min

GET  /v1/balance              # ~12/min  -> { BTC, ETH, USDT, BRL, ... }
GET  /v1/trades?op=buy&base=BTC&page=1&limit=20   # ~12/min, recent fills
  -> [ { id, op, base, baseAmount, quoteAmount, efPrice, date }, ... ]

# History older than the recent-fills window: reconcile from the
# extrato CSV, normalized to the same { id, op, base, ... } schema.

The published rate windows (balance and trades around twelve requests a minute, offers around twenty-four) are part of the design, not an afterthought — a year of history pulled naively will throttle.

Where this plugs in

• Brazilian crypto-tax reporting. Paginated trade fills plus the extrato backfill, normalized into a single dated ledger for an IR crypto declaration, with Bix conversions included.
• Portfolio aggregation. The balance call across BTC, ETH, USDT and BRL folded into a multi-venue net-worth view next to other Brazilian exchanges.
• Best-execution audit. Logging each offer quote against its confirmOffer fill to evidence how the cross-exchange routing priced over time.
• Recurring-buy monitoring. Tracking #bix scheduled Pix-to-Bitcoin conversions so a dollar-cost-averaging program shows up in an accounting feed.

Consent and the Brazilian rulebook

The crypto side of Bity sits under Lei 14.478/2022, the Brazilian virtual-assets law in force since June 2023, with the Banco Central do Brasil resolutions that implement supervision of virtual-asset service providers now in their licensing transition period. We treat those numeric obligations as a moving framework rather than settled fixed thresholds, and scope the integration to the data the client actually contracts for. The BRL and Pix banking leg is the part that maps to Open Finance Brasil consented sharing, where registration and transactional data move under an explicit, revocable consent; the crypto ledger itself is outside that scheme and is reached under the account holder's own credentials.

Practically, that means: access runs against the holder's own key or a consenting account, never a shared one; scope is minimized to the contracted domains; the user can revoke the key at any time and the integration is built to fail closed when they do; access is logged, consent records are kept, and an NDA is in place where the client needs one. Compliance here is how the work is run, not a form the reader has to clear first.

What we plan around on this build

Concrete notes for a Bity integration specifically — things the studio handles, written from our side of the table:

• Two backends, one account. The quote-and-confirm REST path and the Bitypreço PRO trading backend do not share a data model. We map both and document every field that exists in one but not the other, so a combined trade-history feed is whole rather than the simple path masquerading as the full account.
• Quote validity timing. Offers are short-lived because the price is aggregated live across venues and then confirmed. We design the sync so a quote is confirmed inside its window and a lapsed offerId is re-quoted, never silently dropped or blindly retried.
• Rate-limit budgeting. The private endpoints are capped per minute. We size the poller and the historical backfill to those windows so a large pull degrades gracefully instead of tripping throttling mid-run.
• Backfill versus live reconciliation. The REST trades call returns recent fills; deep history for tax comes from the CSV statement. We wire the normalizer so both land in one schema and a fill present in both reconciles to a single record.
• Onboarding access. Keys are generated on the client's own account with us during onboarding, and the PRO-side protocol capture runs against a consenting account — arranged as part of the engagement, not asked of the reader up front.

Screens we mapped

The store screenshots we worked from while tracing surfaces. Select any to enlarge.

How this was put together

The technical surface was checked against the documented Biscoint client library (endpoints, the signed-request model, and the per-minute limits noted there), the Brazilian crypto-tax tutorial that documents Bity's CSV extrato export, the app's own store listings for the package and platform identity, and current writeups of Brazil's virtual-asset framework under Lei 14.478/2022. Checked May 2026; figures attributed to those sources rather than asserted independently.

Sources: Biscoint client library — endpoints, auth, rate limits · Bity/Bitpreço CSV statement export tutorial · Bity App Store listing · Brazil VASP legal framework overview

Mapped by the OpenBanking Studio integration desk · May 2026.

Other Brazilian crypto apps in the same picture

Same-category apps an integrator often unifies with Bity — several of these also supply Bity's price aggregation, so they recur as standalone account sources too. Named neutrally, no ranking.

• Mercado Bitcoin — the largest Brazilian platform by volume; holds per-user balances, order and trade history, and a documented trading interface relevant to a combined ledger.
• Foxbit — a long-running Brazilian exchange with account balances and trade records suited to portfolio and tax aggregation.
• NovaDAX — wide asset coverage in Brazil; balances and trade history that fit a multi-venue net-worth view.
• Bitso — operates across Brazil and Latin America with account, transfer and trade data a unified integration would normalize.
• Coinext — Brazilian exchange holding per-account balances and order history comparable to the Bity REST surface.
• Binance — global venue with deep account, order and transfer data, commonly aggregated next to local Brazilian accounts.
• Bybit — derivatives and spot account data that integrators often fold into the same reporting pipeline.
• Kraken — spot and funding records used in cross-exchange portfolio and tax reconciliation.

Questions integrators ask about Bity

Does the Biscoint REST surface return the same trade history the PRO interface shows?

Not by itself. The REST trades call returns recent fills, paginated and filterable by operation and base asset. The Bitypreço PRO order book and limit/stop detail run on a separate trading backend that we capture through protocol analysis. Full historical operations come from the platform's CSV statement. We reconcile all three to one schema so a trade-history feed is complete rather than partial.

Which Brazilian rules apply to pulling a Bity account's data?

The crypto side sits under Lei 14.478/2022 and the Banco Central do Brasil resolutions implementing the virtual-asset framework. The BRL and Pix banking leg falls under Open Finance Brasil consented sharing where Bity participates as an institution. We work against the account holder's own credentials or a consenting account, keep access data-minimized and logged, and sign an NDA where required.

Can you capture the #bix Pix-to-Bitcoin recurring buys?

Yes. Bix conversions, where a Pix payment to pix@bity.com.br tagged #bix is turned into Bitcoin, land as deposit and conversion records. We normalize them alongside trades so a recurring dollar-cost-averaging feed is auditable next to ordinary buys and sells.

We export the extrato CSV by hand every month for tax — can that become a live feed?

Yes. We keep the CSV statement as a backfill and reconciliation path and put the live account on the Biscoint REST integration, so balances and new fills arrive continuously and the manual monthly download stops being the only source.

One delivery, fixed on this app: runnable source for the Bity balance, trades and quote-confirm calls plus the Bitypreço PRO capture and the CSV normalizer, in your repo from $300, billed only after delivery once you have run it and it works. The other model is our hosted endpoints — you call them and pay per call, nothing upfront. Either path runs on a one to two week cycle. Tell us the app and what you need out of its data at /contact.html; key generation, the consenting test account and the compliance paperwork are arranged with you as part of the work, not asked of you before it starts.