pynubank still ships a clean Nubank client that the bank no longer answers

The README opens with a support notice, not a feature list

The most important paragraph in this repository is the one marked as discontinued support. Since August 2023, the documentation states, Nubank has blocked access to data that is not accompanied by facial verification, which in turn blocked access to the APIs that pynubank depends on. The consequence stated plainly is that the library can no longer be used, and the topic was discussed at length in issue 419, where some alternative solutions were collected. The project asks that new issues not be opened for errors that have already been reported. So the honest framing is this: pynubank is a complete, readable implementation of a private financial API that no longer answers, and the interesting question for a reader is what it does and how it does it, not whether it will work against a live account.

Three login paths, each borrowing a different Nubank surface

Authentication always starts with a CPF and a password, and then adds one more factor, which is where the design gets interesting. The documentation lists three options. The QR code path works the way the web app does, and the note attached to it says it permits access only to credit card data. The certificate path works the way the mobile app does. The third option combines a certificate with a refresh token. Each of these has its own example file in the examples directory, so the login flows are documented separately rather than collapsed into one generic method. The existence of three paths also hints at why the library broke in August 2023: it depends on the bank's own surfaces for proving a session, and when the bank added a check that the library could not satisfy, there was no fallback that would keep the data path alive.

Reading statements, bills and balances through a small object API

The credit card example is short enough to read in one pass. The client is created, authentication is inserted, and then the calls return plain Python structures:

from pynubank import Nubank

nu = Nubank()

card_statements = nu.get_card_statements()
card_statement_details = nu.get_card_statement_details(card_statements[0])
print(sum([t['amount'] for t in card_statements]))

bills = nu.get_bills()
bill_details = nu.get_bill_details(bills[1])

get_card_statements returns a list of dictionaries with all of your credit card transactions, get_card_statement_details returns the details of a single transaction including its installments, get_bills returns the list of invoices, and get_bill_details expands one invoice. The NuConta side mirrors it with get_account_statements and get_account_balance:

account_statements = nu.get_account_statements()
print(sum([t['amount'] for t in account_statements]))
print(nu.get_account_balance())

The interface is thin on purpose. There is no ORM, no pagination helper, no retry policy in the documented surface, which makes the library easy to read and easy to wrap.

MockHttpClient keeps your tests off the bank servers

The documentation carries a warning that Nubank may block your account for 72 hours if it detects abnormal behavior, and advises sending as few requests as possible. The library answers that warning with a mock transport:

from pynubank import Nubank, MockHttpClient

nu = Nubank(MockHttpClient())
nu.authenticate_with_cert("qualquer-cpf", "qualquer-senha", "caminho/do_certificado.p12")

The client is constructed with a mock HTTP client, so no call reaches Nubank, the authentication call succeeds locally with placeholder credentials, and every method returns instantly with fake data. The package ships the fixtures needed for this, because setup.py includes pynubank/utils/mocked_responses/*.json in package_data alongside the GraphQL query files in pynubank/queries/*.gql. That fixture design is the single most reusable part of this repository for anyone writing their own financial data code, because it separates the shape of the data from the network entirely.

A console script and pinned dependencies from 2023

The packaging is plain setuptools, and the version in setup.py is 2.25.0, which matches the last release published on 2023-06-20. The entry point registers a console script named pynubank that maps to pynubank.cli:main. The runtime dependencies are pinned to exact versions rather than ranges:

requests==2.31.0
qrcode==7.3.1
pyOpenSSL==23.2.0
colorama==0.4.3
requests-pkcs12==1.13
Deprecated==1.2.14

Those pins tell you what the library needs: HTTP requests, QR code rendering, OpenSSL for the certificate based login, a helper for extracting the client certificate from a p12 file, and a deprecation shim. The classifiers list Python 3.7 through 3.10, so the project targets interpreter versions that are all older than what most teams now run. Installation is a single command:

pip install pynubank

Development setup follows the usual shape, with requirements.txt for runtime and requirements-test.txt for the test extras:

pip install -r requirements.txt
pip install -r requirements-test.txt
pytest

NuConta amounts arrive unsigned, so the type name carries the direction

One detail in the NuConta example is worth isolating, because it is the kind of thing that produces wrong numbers silently. The documentation notes that outgoing transactions do not carry a negative value, so the direction has to be read from the __typename property instead. TransferInEvent is an incoming transaction, TransferOutEvent is an outgoing one, and TransferOutReversalEvent is a refund. The example sums the amounts with a plain sum, but the type name is what tells you whether to subtract. This is a reasonable place to point out that a bank that does not sign outgoing amounts is pushing the arithmetic onto the client, and any code built on this library has to carry that correction itself.

Unmaintained by the bank, still maintained by its owner

The licence is MIT, and setup.py carries the same identifier. The code therefore remains usable and reusable, and the MIT terms are permissive enough that a fork of the client logic is a normal option. What has stopped is the connection to the service. The release history is the clearest evidence: 2.23.0 on 2023-05-09, 2.24.0 on 2023-06-18, 2.25.0 on 2023-06-20, and then nothing published since, while the last push was on 2026-05-15. Commits continued to land without a release, which usually means packaging fixes and dependency bumps rather than new capability. Against that background, the README links the JavaScript version this library was based on, but switching languages does not solve the blocking. The alternative that does work is the one the project points at, the alternative solutions gathered in issue 419, and the honest fallback for a real account is the bank's own channels. For a test suite, the alternative is MockHttpClient, which needs no bank account at all.

Editorial conclusion

pynubank is worth reading and copying from, and not worth installing for a live integration, because the project itself says the library can no longer be used against the bank. It suits developers who want the GraphQL query shape, the authentication flows and the mock client for tests, and it does not suit anyone expecting a maintained connection to a Nubank account, since the last release was 2.25.0 on 2023-06-20 while the last push was on 2026-05-15. Before you build on it, check the current state of the linked issue 419 for the alternative approaches its maintainers collected, and if you do use the code, keep MockHttpClient in your test path so that nothing in CI sends a request to the bank.

Frequently asked questions

Official sources

1. andreroggeri/pynubank on GitHub
2. Issues
3. License: MIT
4. README
5. Releases