Back to dashboard

Use DMM as a download client in Radarr / Sonarr

DMM can pretend to be a SABnzbd server. Radarr and Sonarr grab a release from your Usenet indexer as usual, DMM pulls it off Usenet, rebuilds it as a torrent and adds it to your own Real-Debrid account. The finished release appears in your zurg/rclone mount, and *arr imports it from there.

1. Your Real-Debrid API token

This is both your password and your identity here — jobs are filed under it, so *arr only ever sees your own queue. It goes in SABnzbd's API Key field.

Get it at real-debrid.com/apitoken. Nothing is stored — this page keeps it in the browser tab only, and it is cleared when you close it.

Use the permanent API token from that page, not a token copied out of a logged-in session. Session tokens rotate, and when one does your download client stops authenticating and its queue and history go empty — the jobs are filed under the old token.

2. Where the finished release will appear

Your zurg or rclone mount root, written exactly as Radarr sees it — if *arr runs in Docker, that is the path inside its container. DMM has no view of your filesystem; it only names this path in history so *arr knows where to import from.

Leave it blank if you only want *arr to track progress. Everything still works; there is just nothing for it to import.

On a zurg nightly? Import from __magic__ instead

Use /mnt/zurg/__magic__/__all__ here and put your Radarr and Sonarr root folders in __magic__ next to it, like __magic__/movies. Every import is then instant and downloads nothing.

Importing straight from __all__ is risky. After each import, Radarr and Sonarr delete the download folder there. On a zurg nightly older than 2026.10.04.2240 that deletes the release from your Real-Debrid account, along with what was just imported.

In Docker, give Radarr and Sonarr one volume that holds the whole mount, so this folder and the root folders are on the same volume. Why. zurg-public has no __magic__, so keep __all__ there.

No mount yet? You need zurg.

zurg exposes your Real-Debrid library as a filesystem, which is what gives this a path to import from — and what Plex, Jellyfin, Emby and Infuse read.

3. Paste this into Radarr / Sonarr

Settings → Download Clients → + → SABnzbd.

Host
(leave blank)
Port
(leave blank)
Use SSL
no
URL Base
api/sabnzbd/mnt/zurg/__all__
API Key
(leave blank)
your Real-Debrid token, from step 1
Username
(leave blank)
Password
(blank, or your DMM API key)
sponsors only, for the allowance below
must be one of these, or *arr's test fails with “Category does not exist”

4. Check it before you save

Checks more than Radarr's own Test does — see below.

Daily allowance

The same as sending releases from DMM's own pages, and shared with them. Each Real-Debrid account can pull 300 GB of Usenet in any 24 hours. Grabs past that wait in the queue and start on their own as the allowance frees up, so *arr shows them queued, not failed.

Sponsors get 2 TB and a place ahead of the normal queue. *arr cannot tell DMM you sponsor, so put your DMM API key in the Password field above. Without it a sponsor's grab counts as a normal one. Both last as long as your sponsorship. A grab still waiting when it ends moves back to the normal queue and allowance.

What to expect once it is running

  • A grab sits in *arr's queue while the work happens. The bar covers two passes: 0–50% is DMM pulling the release off Usenet, 50–100% is Real-Debrid pulling it from DMM. It is not stuck at 50%.
  • Big releases take a while — every byte has to cross DMM before Real-Debrid can be handed a torrent. There is no cached shortcut.
  • The release lands in your Real-Debrid account under its own name, which is the folder name that shows up in your mount.
  • Removing an item in *arr removes the job here too. You can only touch your own — jobs are scoped to the API token that created them.
  • The Usenet bandwidth is the operator's, not yours. Please do not point a large backlog at it.