qBittorrent-compat API: broaden beyond *arr-specific endpoints toward full WebAPI v2 parity

[gianfelicevincenzo]

Hi. I tried connecting to qBittorrent using Python (via qbittorrent-api). When I try to log in, I get an Unauthorized error, even though the credentials are correct.

qbittorrentapi.exceptions.Unauthorized401Error: {"success":false,"message":"You must be logged in to access this resource"}

It's normal?

[got3nks]

@gianfelicevincenzo important detail to nail down: which server is your qbittorrent-api Python client actually pointing at?

• If you're pointing it at your real qBittorrent instance's port (e.g., 8080), that's a qBittorrent-side problem, not aMuTorrent — check qBittorrent's WebUI settings and credentials directly.
• If you're pointing it at aMuTorrent's port (typically 3000/4000) to use our qBittorrent-compatible API, then this is our side, and the specific error you got points to a routing issue.

The reason I ask: the error message you got — "You must be logged in to access this resource" in that exact JSON shape — is from aMuTorrent's general auth middleware, NOT our qBittorrent-compat router. Our compat router returns 403 Forbidden: Session expired / 403 Forbidden: Invalid bearer token on auth failure, with a different response shape.

If your client IS hitting aMuTorrent, this means the request is falling through the compat router entirely and hitting the catch-all requireAuth — which happens when the URL doesn't match a route we've implemented. Common causes:

1. Missing /v2/ in the path — qbittorrent-api uses /api/v2/* by default; if it's somehow calling /api/* (older API or a config quirk) it won't match anything in our compat layer.
2. Endpoint we don't implement — our compat layer covers the routes Sonarr / Radarr / Prowlarr need. If qbittorrent-api's Python method calls one we haven't implemented, Express returns nothing → falls through to requireAuth 401.
3. Wrong port — pointing at the wrong service.

Could you share:

• The Python snippet you're using (specifically the Client(...) init line and the method call that fails)
• The aMuTorrent URL you're connecting to
• Which aMuTorrent version (v3.8.7?)

If you're on v3.8.7, integration doc is at INTEGRATIONS.md — the qBit-compat section covers the supported endpoints and the two auth modes (per-user API key via Authorization: Bearer header, or username/password via POST /api/v2/auth/login + SID cookie).

[gianfelicevincenzo]

It's a simple login init. The connection is via localhost:4000

qbt_client = qbittorrentapi.Client(host_qbittorrent,port_qbittorrent,username_qbittorrent,password_qbittorrent)
qbt_client.auth_log_in()

The version Amutorrent is latest (3.8.7)
The connection via Radarr/Sonarr is working fine. Same credentials, same port, same address.

[got3nks]

Thanks — that narrows it to something specific about how qbittorrent-api builds the request. Sonarr and Radarr use classic username/password → SID cookie against the same endpoint on the same port, so our /api/v2/auth/login + subsequent auth path works end-to-end.

A couple of things to help narrow this down:

1. Try the full URL as host. qbittorrent-api can be finicky about port vs full URL — try:

qbt_client = qbittorrentapi.Client(
    host='http://localhost:4000',
    username=username_qbittorrent,
    password=password_qbittorrent,
    VERIFY_WEBUI_CERTIFICATE=False,
    FORCE_SCHEME_FROM_HOST=True
)
qbt_client.auth_log_in()

FORCE_SCHEME_FROM_HOST=True tells the library to honor the http:// we passed rather than trying HTTPS. Some versions of the library default to HTTPS silently, which would fail differently but is worth ruling out.

2. Verify the raw login call works with curl — this bypasses the Python library entirely and confirms whether our endpoint is reachable at that path:

curl -v -X POST http://localhost:4000/api/v2/auth/login \
  -d 'username=YOUR_USER&password=YOUR_PASS' \
  -H 'Referer: http://localhost:4000'

Expected: HTTP/1.1 200 OK with a Set-Cookie: SID=... header. If that works, the endpoint is fine and the issue is qbittorrent-api's request shape.

3. Enable qbittorrent-api's debug logging to see what URL/headers it's actually sending:

import logging
logging.basicConfig(level=logging.DEBUG)

The full request URL + headers in the debug output would tell us definitively whether it's hitting /api/v2/auth/login or falling through to requireAuth (would indicate the URL is off).

4. Try the Bearer API key mode — that's what modern Sonarr uses. If it works and username/password doesn't, we've isolated the specific auth path:

qbt_client = qbittorrentapi.Client(
    host='http://localhost:4000',
    EXTRA_HEADERS={'Authorization': f'Bearer {YOUR_AMUTORRENT_ADMIN_API_KEY}'}
)
qbt_client.torrents_info()  # skip auth_log_in() entirely

You'll find your admin API key under Settings → User Management → your admin user → API Key.

Please share the debug log output from #3 and I'll pinpoint what's mismatched.

[gianfelicevincenzo]

My version of qbittorrent-api (qbittorrent-api==2026.7.0) is 5.1.4

The debug connection (I used the code from point 1)

2026-07-13 16:53:14 [DEBUG] Re-initializing context...
2026-07-13 16:53:14 [DEBUG] Parsed user URL: ParseResult(scheme='http', netloc='localhost:4000', path='', params='', query='', fragment='')
2026-07-13 16:53:14 [DEBUG] Base URL: http://localhost:4000/
2026-07-13 16:53:14 [DEBUG] Starting new HTTP connection (1): localhost:4000
2026-07-13 16:53:14 [DEBUG] http://localhost:4000 "POST /api/v2/auth/login HTTP/1.1" 200 3
2026-07-13 16:53:14 [DEBUG] Login successful
2026-07-13 16:53:14 [DEBUG] http://localhost:4000 "GET /api/v2/app/version HTTP/1.1" 200 6
2026-07-13 16:53:14 [DEBUG] http://localhost:4000 "POST /api/v2/torrents/info HTTP/1.1" 401 75

Wait. But looking more closely... the login actually succeeds. It's the for loop over the torrents that seems to be causing an error. Why is that?

for torrent in qbt_client.torrents_info(category=category,torrent_hashes=args.hash_release):
   print(torrent)

I also tried using the code from point 4, but it doesn't work either.:

2026-07-13 17:00:24 [DEBUG] Parsed user URL: ParseResult(scheme='http', netloc='localhost:4000', path='', params='', query='', fragment='')
2026-07-13 17:00:24 [DEBUG] Detecting scheme for URL...
2026-07-13 17:00:24 [DEBUG] Starting new HTTP connection (1): localhost:4000
2026-07-13 17:00:24 [DEBUG] http://localhost:4000 "HEAD / HTTP/1.1" 302 0
2026-07-13 17:00:24 [DEBUG] http://localhost:4000 "HEAD /login HTTP/1.1" 200 0
2026-07-13 17:00:24 [DEBUG] Using HTTP scheme
2026-07-13 17:00:24 [DEBUG] Base URL: http://localhost:4000/
2026-07-13 17:00:24 [DEBUG] Starting new HTTP connection (1): localhost:4000
2026-07-13 17:00:24 [DEBUG] http://localhost:4000 "POST /api/v2/torrents/info HTTP/1.1" 401 75

[got3nks]

Thanks — that debug output pinned it exactly. Look at your last line:

POST /api/v2/torrents/info HTTP/1.1" 401 75

qbittorrent-api sends /torrents/info as POST. Our compat layer registers it as GET-only (qbittorrentAPI.js:220), so no route matches → Express falls through to the general auth middleware → 401. Real qBittorrent's WebAPI v2 spec accepts both methods; Sonarr/Radarr happen to send GET, which is why they work.

Scope note worth being explicit about: our qBittorrent-compatible API isn't a full drop-in replacement for real qBittorrent's WebAPI. It's a targeted compatibility layer implementing the specific endpoints and request patterns that Sonarr, Radarr, and Prowlarr actually use for their "qBittorrent download client" integrations. That's what we test against and what we guarantee.

Third-party clients like qbittorrent-api may work by coincidence when their calls happen to overlap with the *arr call patterns (as your login + /app/version calls did), but full spec compliance — every method, every parameter, every optional endpoint — isn't in scope right now and expanding it would add a maintenance surface I can't commit time to.

Leaving this open as a tracking item for "broaden qBit-compat surface toward full spec parity" — no timeline attached, but it's a real feature request and worth having on the record so if others land here with the same need we can gauge demand.

For your immediate need, two options that work today:

1. Use the Bearer API key mode directly — bypasses the login flow entirely and works well with qbittorrent-api's EXTRA_HEADERS. Full example in my previous comment (option 4).
2. Use aMuTorrent's native REST API — under /api/* (not /api/v2/*), with an X-API-Key header. Better shape for scripting since there's no qBittorrent-emulation baggage.

Thanks for the well-documented report — the debug log made the diagnosis trivial.

[gianfelicevincenzo]

Let me explain why I'm doing this. Since Radarr and Sonarr have certain key features, I’ve enhanced them by interfacing my own scripts with the applications via connectors and webhooks; in some respects, my scripts handle things better than Radarr or Sonarr do. For instance, some movies are reported with incorrect details (like flagging Italian audio when it isn't actually present), which causes infinite loops. I don't have this issue with qBittorrent because, at the moment of the "grab," I check the queue and the movie's history; if a download identical to one already completed for that movie is queued, I delete it (see my other issue—I think I've figured out the problem there, too - #69 ). The issue persists with aMule because, as far as I can tell, I can't easily integrate with the "classic" qBittorrent API. So, I'll try one of the two solutions you suggested. Thanks a lot 👍