← ClaudeAtlas

qonto-accesslisted

Access layer for the Qonto Business API across several companies - one key per organization, group balances, transactions, pagination, rate limits, pitfalls. Read-only. Load before any Qonto task, especially when more than one company is involved.
Xileades/qonto-api-toolkit · ★ 0 · Testing & QA · score 70
Install: claude install-skill Xileades/qonto-api-toolkit
# Qonto - multi-company access layer Any task hitting the Qonto API starts here. The native Qonto connector sees one organization; this library sees all the ones declared in `tokens.json`. ## 1. Bootstrap ```powershell . .\lib\qo-api.ps1 ``` If the library is shared from a network drive, copy it locally first: the `RemoteSigned` policy refuses an unsigned `.ps1` on a network path. Keep the share as the source of truth and the local copy as a cache overwritten at every run. Do **not** work around it by setting the policy to `Bypass`. If `qo-api.ps1` throws "tokens.json not found", point the user at the README. Never guess a key, never reuse someone else's, never print or log one. ## 2. Companies and keys **One Qonto key is bound to one organization.** Hence one entry per company in `%USERPROFILE%\.qonto\tokens.json`, never on a share, never in git. Each entry has a `login` (organization identifier) and a `secret`, both shown in the web app under *Integrations and partnerships → API key* after switching to that organization. Pre-flight before anything unusual: ```powershell QOEntites # available companies QOMe 'my-company' # legal_name: is it the company you expect? ``` ## 3. Calling the API Base `https://thirdparty.qonto.com/v2`, header `Authorization: <login>:<secret>` - raw concatenation, **no `Bearer`, no Base64**. `QOHdr` builds it. | Function | Role | |---|---| | `QOEntites` | companies in tokens.json | | `QOMe $e` | pre-flight: which company ans