What sits behind the Coinext login, and the authorized way to reach it

The Coinext app talks to an AlphaPoint trading backend reached at api.coinext.com.br on port 8443, trading JSON over HTTP requests and a parallel WebSocket channel — that detail surfaces in the protocol once you watch the traffic. Coinext is a Brazilian exchange founded in 2017 in Belo Horizonte, with more than 410 thousand customers per its Play Store listing. Behind one account sit a BitGo-held wallet across BTC and 60-plus assets, a full order history, Pix deposits, BRL withdrawals, and Smart Wallet automated trades. Most of that is structured, per-user, and reconcilable. The job is to reach it the authorized way and hand back something runnable.

Bottom line: the data you would want from Coinext lives behind a token-authenticated service layer, and the most durable way in for a third party is the account holder's own consent rather than anything scraped from the front end. We map that service layer, reconstruct the order and settlement ledger, and ship a client you can run.

The records a Coinext account actually holds

Each row is something the app shows a user and the backend stores, named close to how Coinext labels it.

Three authorized ways in, and the one we lean on

Protocol analysis of the AlphaPoint service layer

The app drives a documented set of named services — WebAuthenticateUser, GetUserInfo, CreateQuote, CancelOrder and the order-book reads — over https://api.coinext.com.br:8443/AP/<Service>, with a WebSocket variant for live updates. Mapping that traffic gives the richest, freshest reach: real-time balances and order state, not a daily snapshot. Effort is moderate; durability is good as long as we re-check when the service contract shifts. We set up the capture against a consenting account during onboarding.

User-consented account access

For a third party acting for the account holder, the dependable basis is that holder's explicit consent. With it, we authenticate as the user (session token or an issued API key/secret), pull their own records, and keep a consent record on file. This is the route we recommend for Coinext, because it is the one that survives audits and does not depend on front-end markup staying still — the consent itself is the durable thing, and the AlphaPoint protocol mapping rides on top of it. Pair the two and you get reach plus a defensible footing.

Native statement export as the backstop

Coinext lets a user generate two reports — Ordens Executadas and Depósitos e Saques — from the Relatórios section. That is the lowest-effort path and a clean fallback for historical backfill, though it is a point-in-time pull rather than a live feed, and the two files have to be joined to reconstruct a full round trip.

On the wire

Illustrative request shape, confirmed against the protocol during the build — login yields a token, the token rides in a header on later calls.

# 1) Authenticate -> token
POST https://api.coinext.com.br:8443/AP/WebAuthenticateUser
Authorization: Basic base64(login:password)
--> { "Authenticated": true, "SessionToken": "<tok>", "User": { "UserId": 12345 } }

# 2) Authenticated read, token carried in aptoken header
POST https://api.coinext.com.br:8443/AP/GetUserInfo
aptoken: <tok>
{ }
--> { "UserId": 12345, "AccountId": 67890, "UserName": "...", "VerificationLevel": 3 }

# Key-based alternative: sign the payload
#   signature = HMAC_SHA256( apiSecret, nonce + userId + apiKey )
#   sent alongside apiKey + nonce; no interactive login needed

# Error path observed: bad/expired token -> { "errormsg": "Not_Authorized", "result": false }
# Long backfills re-call WebAuthenticateUser when the session lapses.
      

What lands at the end

Everything is scoped to the surfaces above, not a generic kit.

• An OpenAPI/Swagger spec covering the services we use — auth, GetUserInfo, order reads, the statement-equivalent pulls — with field types as observed.
• An auth-flow report documenting both paths: the WebAuthenticateUser token in the aptoken header, and the HMAC-SHA256 key/secret signing, including session-refresh behaviour.
• Runnable client source in Python and Node.js for login, balance and order pulls, and the two report exports, with the order and cash-flow records normalized into one ledger schema.
• Automated tests run against a consenting account, plus fixtures for the error paths.
• Interface documentation and LGPD-aligned data-retention guidance for what you store and for how long.

Consent, and the regime Coinext now sits under

As a Brazilian virtual-asset provider, Coinext falls under the framework the Banco Central do Brasil published on 10 November 2025 — Resolutions 519, 520 and 521, which define the SPSAV authorization, take effect in February 2026, and give existing operators a grandfathering window through October 2026. Personal data is governed by the LGPD. Neither of those is a wall we put in front of you; they shape how we work. Access is built on the account holder's authorization, every pull is logged, the consent record is kept, and we retain the minimum the integration needs. NDAs are standard where the work touches anything sensitive. Note that Brazil's Open Finance program is a separate track for BCB-authorized financial institutions, so the consented-access route, not an open-banking mandate, is what carries a crypto exchange like this one.

Things we account for in the build

• Session lifetime. The aptoken session expires, so we design any long backfill to re-authenticate mid-run instead of letting a multi-hour pull die silently halfway through.
• Automated fills. Smart Wallet trades land in the same fills stream but are not user-placed orders; we model them on a separate axis so an algorithmic fill is never double-counted against a manual Market or Limit order.
• Two-file statements. The native export splits executed orders and deposits/withdrawals into different reports; we join them on timestamp and asset so a single Pix-in, buy, send-out sequence reconciles as one event.
• HTTP and WebSocket together. Point-in-time reads come over the HTTP services while balance and order-book changes stream over the socket; we wire both so live state is captured, not just a snapshot.

What the app surfaces look like

How this was checked

Reviewed on 5 June 2026. I read Coinext's own developer notes for the service layer and authentication, the AlphaPoint key-generation utility used as a Coinext example, a Brazilian tax-tooling FAQ that documents the two-statement export, and the Banco Central framework coverage for the VASP resolutions. The user count and founding details are as stated on the app's Play Store listing.

• Coinext service-layer developer notes
• AlphaPoint key/secret utility (Coinext example)
• Coinext statement-export guide (Ordens Executadas, Depósitos e Saques)
• BCB Resolutions 519/520/521 — VASP framework

Mapped by the OpenBanking Studio integration desk · 5 June 2026.

Comparable exchanges in one integration

If you are unifying more than one Brazilian venue, these come up alongside Coinext. Several share the AlphaPoint lineage, so a client built for one transfers in part to the others.

• Mercado Bitcoin — the largest local exchange; holds balances, order history and BRL movements for a very large user base.
• Foxbit — long-running BRL exchange with wallet, trade and fiat-transfer records per account.
• NovaDAX — broad coin listing; per-user balances, orders and deposit/withdrawal logs.
• Ripio Trade — Brazilian order-book exchange with structured trade and settlement data.
• Bitso — pan-Latam platform holding balances, trades and Pix/SPEI fiat flows.
• Bitybank — BRL-focused exchange with account balances and transaction history.
• Binance — global venue used heavily in Brazil; deep order, wallet and transfer records.
• Coinbase — international exchange with per-account holdings and trade histories some Brazilian users hold alongside a local venue.

Questions an integrator tends to ask

Do Smart Wallet automated trades show up the same way as manual orders?

They share the same fills feed but not the same origin. A Smart Wallet fill is generated by Coinext's automation rather than a user-placed Market, Limit or Stop order, so we tag it on a separate axis and keep it from being double-counted against a manual order when we rebuild the trade ledger.

Which Brazilian rules cover pulling data out of Coinext?

Coinext is a Brazilian virtual-asset service provider, so it falls under the BCB framework set by Resolutions 519, 520 and 521 (published November 2025, effective February 2026) and personal data is governed by the LGPD. We work from the account holder's own authorization, log every pull, and minimize what is retained.

Can Pix deposits and BRL withdrawals be reconciled to on-chain transfers?

Yes. The deposit and withdrawal records sit in one statement stream and the executed orders in another; we join them on timestamp and asset, then line the BRL legs up against the blockchain transfer records so a single Pix-in, buy, send-out round trip reads as one reconciled event.

How do you handle the token versus API-key authentication paths?

The service layer accepts a session token obtained from WebAuthenticateUser and carried in an aptoken header, and a key-based path that signs requests with HMAC-SHA256 over the API secret. We document both in the auth-flow report and pick whichever the consenting account is set up for, with session refresh wired in for long backfills.

For a fixed fee from $300 we hand over the runnable source and docs, billed only after delivery once you have looked them over and are satisfied. Prefer not to host anything? Call our endpoints instead and pay per call, with nothing upfront. You give us the app name — Coinext — and what you need out of it, say a reconciled order-and-cash-flow ledger; access and the consent paperwork are arranged with you as we go, not handed to you as homework. Typical turnaround is one to two weeks. Start the conversation at /contact.html.