Knaben
- Free allowance
- No key and no account: GET https://api.knaben.org/v2/search?q=... returned hits with hash, magnetUrl, tracker, seeders and bytes.
- Verdict
- ★ qualifiesusable as stated; the read path was probed
- Cost
- free tier
- Identity
- anonymousno card, no phone
- Binding limit
- request-rateno number published; the v2 docs justify the rewrite with 'we've been struggling to serve the amount of bandwidth from the server to all the API clients' and close with 'if you alone are the main reason the server CPU sits at 100%, I...
- Evidence
- documented3 sources; a first-party page was read and the sentence quoted
- Freshness
- stale on 2026-11-23checked 2026-10-23 (live); stale on 2026-11-23
| Free tier | No key and no account: GET https://api.knaben.org/v2/search?q=... returned hits with hash, magnetUrl, tracker, seeders and bytes. The docs publish no quota. unit requests; metered on request-count |
|---|---|
| Price | USD 0 |
| Limits |
v2 moved from POST to GET so the edge can cache the responses, which is a bandwidth measure rather than a per-client quota. The 300-result ceiling is the only hard number, and six concurrent requests drew no 429. |
| Binding | request-rate The operator names CPU and bandwidth as the failure mode and refuses to publish a number, so a user's own restraint is the only limit; no byte quota exists on this side. |
| Identity | anonymous No key, no account, no captcha on the GET requests made today. |
| Egress | no byte allowance: the API returns JSON records and magnets free allowance: none published |
| Per-object cap | not applicable: results are metadata and magnets |
| Retention | the database keeps documents after they go dead; the docs say 1.7 million documents were seen in the last week and the 'dead' flag is opt-in |
| Interface | rest GET /v2/search and GET /v2/browse with query parameters (q, sf, c, t, o, d, s, f, xxx, unsafe, dead, seen); size maximum 300. v1 still exists as POST /v1 with a JSON body. There is also an RSS page at knaben.org/rss/. |
| Tooling | One GET. Sonarr/Radarr-style clients reach it through Torznab proxies; TorrentClaw lists Knaben as one of its sources, so the API is already the feed behind another index. |
| Composes with | Query by title, take the magnetUrl or hash, hand the hash to a debrid service's cache check, and only fetch the ones that come back cached. |
| Reliability | Bandwidth pressure is stated by the operator, and the API answers are edge-cached (Cache-Control public with s-maxage 300), so a stale page can show a torrent that has since gone dead. |
| Notes | The best machine-readable torrent feed that needs nothing: no key, documented parameters, 300 results per call, and a magnet in every hit that carries a hash. Its weakness is exactly the thing asks about: the operator publishes no rate, only a threat. |
| Evidence note | documented Both doc pages and a live v2 response were read on 2026-10-23. A sustained poll with recorded statuses would raise the rate row to measured. |
| Parsed numbers |
|
Evidence 3
| date | source | what it proved |
|---|---|---|
| 2026-10-23 | knaben.org/api/v2/ | the full parameter table, the 300-result maximum, the bandwidth rationale and the 'server CPU sits at 100%' warning |
| 2026-10-23 | api.knaben.org/v2/search?q=ubuntu&s=2 | HTTP 200 JSON with hits containing hash, magnetUrl, tracker, seeders, bytes and virusDetection, with no key |
| 2026-10-23 | knaben.org/api/v1/ | v1 is a POST/GET endpoint with the same fields and the same warning, and states the DB holds 1.7 million documents seen in the last week |
More fields 4
| max results | 300 |
|---|---|
| protocol | rest-json |
| auth | none |
| cache s maxage | 300 |