Sign in
1
Your browser opens at Qonto
Sign in if you are not already, pick the organization to connect, and review what the CLI is asking to do.
2
You consent
Qonto sends your browser back to a page that
qonto serves on your own machine (http://127.0.0.1:53683/callback), which completes the sign-in.3
The session is stored
The CLI stores the session in your operating system’s credential store and prints the scopes you granted. From then on, every command uses that session.
Signing in from a remote machine
On an SSH session or in a container, the browser on your laptop cannot reach the CLI’s local page. Use--manual:
http://127.0.0.1:53683/callback) and paste it into the terminal.
Useful login flags
What the CLI can do on your behalf
The CLI acts as you:- It cannot exceed what your role and your organization’s price plan allow. A command your role cannot perform fails with the API’s authorization error.
- It is limited to the scopes you granted when you signed in. By default the CLI asks for every scope its commands use; Available OAuth scopes explains each one. To grant more after narrowing them with
--scopes, sign in again. - It cannot make payments. The CLI is not allowed to request the payment, transfer, or beneficiary scopes, so no session it opens can use them.
- Sensitive actions still require Strong Customer Authentication: the command waits while you approve in the Qonto app. See Strong Customer Authentication.
--help on any command shows the OAuth scope it needs.
Where the session is kept
The session (an access token and a refresh token) is stored in your operating system’s credential store:
Nothing is written to disk in clear text. The configuration file (
~/.config/qonto/config.yaml) never contains a token.
Machines without a credential store
A bare server, a container, or a CI runner usually has no credential store, soqonto auth login cannot save the session there. On those machines, --store-cleartext keeps the session in ~/.config/qonto/credentials.json instead:
That file is not encrypted. It is readable only by your user, but anyone who can read it, including a backup, another administrator of the machine, or any program running as you (an AI agent with shell access among them), can act on your Qonto account until you sign out or revoke the access. Use it only on machines you control, with the narrowest
--scopes list the job allows, and never copy or commit the file.--store-cleartext (or set QONTO_CLI_STORE_CLEARTEXT=1) on every command that should use that session. The setting cannot be put in the configuration file.
Using a token you already have
If you already have an access token, for example in a CI job, set it inQONTO_CLI_ACCESS_TOKEN. The CLI uses it for that command instead of the stored session and never saves it. Access tokens expire after an hour and this mode cannot renew them.
Session commands
Reviewing and revoking access
The CLI appears in the connected apps section of your Qonto account like any other app you have authorized. Revoking it there stops every session on every machine; the CLI then asks you to sign in again.qonto auth logout cleans up the machine you run it on and revokes that session’s tokens. Revoking in Qonto cleans up everywhere. Doing both is the safest way to disconnect completely.