nzbfast with Sonarr & Radarr

nzbfast speaks the SABnzbd API natively, so the *arrs treat it as SABnzbd with no plugins, no patches and no shim. It speaks NZBGet's JSON-RPC API too, and it can act as their indexer. Add it as a download client and you are done in about a minute.

There are two ways to connect, and you only need one. Add nzbfast as a SABnzbd download client is the route to take unless you have a reason not to: it is the better-covered of the two APIs and it is what the rest of this page assumes.

You need two things. The address of your nzbfast machine (http://your-host:6789) and your API key. The key is in the dashboard under Settings → Security, behind a reveal. On an install that has not downloaded anything yet the Welcome card also hands you the address with a Copy button beside it.

As a download client · about a minute

  1. Open the download client settings

    In Sonarr or Radarr: Settings → Download Clients, press +, and choose SABnzbd from the list. Not "Usenet Blackhole", and not NZBGet unless you are deliberately taking the other route below.

  2. Fill in four fields

    FieldValue
    Hostthe machine nzbfast runs on, e.g. 192.168.1.10. Use localhost only if the *arr runs on the same machine, and see the Docker note below if either side is in a container.
    Port6789, unless you changed it.
    API Keyyour full API key from Settings → Security.
    Categorytv in Sonarr, movies in Radarr. See the mapping below.

    Leave Username and Password empty. nzbfast authenticates on the API key alone.

  3. Press Test

    You want a green tick. If it goes red, the message is the useful part and the troubleshooting section at the foot of this page names the two you are most likely to see. Then Save.

In Docker? A container cannot reach localhost on its host. If the *arr is containerised and nzbfast is not, use the host's LAN address, or host.docker.internal on Docker Desktop. If both are containers on one Docker network, use nzbfast's container name.

Categories, and where files land

The category you type into the *arr is passed straight through, and nzbfast files the finished download in a folder named after it, under your completed folder. This is the same arrangement SABnzbd uses, so an existing Remote Path Mapping keeps working.

Set inCategoryFinished download lands in
Sonarrtv<completed>/tv/<release name>
Radarrmovies<completed>/movies/<release name>
Lidarrmusic<completed>/music/<release name>
Whisparr v2tv<completed>/tv/<release name>
Whisparr v3whisparr<completed>/whisparr/<release name>
ReadarrReadarr<completed>/Readarr/<release name>
anything elseyour own name<completed>/<name>/<release name>

You do not have to make the folders first. A category the daemon has not seen is accepted and its folder made on the spot, and the *arr's own category dropdown is filled from whatever nzbfast reports.

The Test button is the exception, and it is the first thing you press. An *arr checks its category against the list nzbfast reports before there is any job to create it, so a category nzbfast has never heard of fails with "Category does not exist". Four are built in: tv, movies, music and books. Two clients ship a default that is not one of them, so out of the box they need one line changed: Whisparr v3 (its default is whisparr) and Readarr (its default is Readarr, with the capital). Either point that client at music or books, or add its name in nzbfast under Settings → Categories. Both work; the Test passes immediately afterwards.
The folder name is not always the release name. When nzbfast recognises a film it may file it under a tidied name instead. That is safe for the *arrs, which match a finished download by its job id and read the real path back from nzbfast rather than guessing it. It is worth knowing about if you point some other tool at the completed folder and expect the release name.

Newznab category numbers

These matter only if you also switch the built-in indexer on and let the *arrs search it. nzbfast classifies each release it indexes and answers with the standard Newznab number:

NumberMeaning
2000Movies
5000TV
4000PC
8000Other. Not 7000, which is Books in the standard tree.

Matching is parent and child, which is what makes this work without any configuration on your side: a release answered as 5000 is returned for a query scoped to 5000 and for one scoped to a TV subcategory such as 5040, while a movie query does not match it.

As an indexer, on its own or through Prowlarr

With the built-in indexer switched on, nzbfast serves Newznab from its own index of the groups you scan. This is an addition to your usual indexers rather than a replacement: it finds what was posted under a real filename, which is a slice of Usenet rather than all of it.

Switch it on first. Settings → Indexing in the dashboard. It is off by default, and while it is off every Newznab query is answered with <error code="101"> rather than an empty list, so a mistake shows up when you add the indexer instead of silently finding nothing for weeks.
  1. Add a Newznab indexer

    In Sonarr, Radarr or Prowlarr: Settings → Indexers+Newznab (in Prowlarr, Generic Newznab).

  2. Fill in three fields

    FieldValue
    URLhttp://your-host:6789/newznab
    API Path/api
    API Keythe same key as above.
  3. Test

    The test runs a real search. If your index is still empty it will say so rather than pass, which is correct: let a scan finish first, then test again.

Searches work by name or by id. Series take a TVDB, IMDb or TVmaze id and films an IMDb or TMDB id, and the client reads which are supported from the capabilities response. Through Prowlarr, the indexer syncs to Sonarr and Radarr like any other, and NZB downloads are handed back through Prowlarr's own proxy.

The NZBGet route

If you would rather connect as NZBGet, nzbfast serves the JSON-RPC API at /jsonrpc. Choose NZBGet in the download client list and fill in the same host and port, with any username you like and your API key as the password. Post-processing parameters, categories and history all behave as the *arrs expect.

Pick one route, not both. Two clients pointed at the same daemon will both report the same downloads and the *arr will not thank you for it.

What has actually been tested

Every release is certified against real, unmodified clients rather than against a reading of their documentation. The rounds of 28 and 31 August 2026 ran stock clients with no patches on either side, carrying a real, playable video and a real album the whole way, so the clients marked media import below were watched reading the file and filing it in their own library. The last of them posted that video the way most real posts arrive, as a multi-volume RAR set that has to be unpacked before there is a media file to import at all:

ClientVersionCovered
Sonarr4.0.19Test dialog, grab, queue, completed pickup, media import (including from a multi-volume RAR post, and from one whose damaged volumes were repaired from PAR2 before unpacking), categories, failed download and blocklist, both the SABnzbd and NZBGet routes
Radarr6.3.0Test dialog, grab, queue, completed pickup, media import (including a download it did not grab itself, one whose post carried PAR2, and multi-volume RAR posts whose file name inside the archive is obfuscated), categories
Prowlarr2.5.2Indexer test, search, NZB fetch, indexer sync into Sonarr
Lidarr3.1.0Test dialog, grab, queue, completed pickup, media import of a full 12-track album, categories, failed download and blocklist
Whisparr2.2.0 and 3.4.0Test dialog, queue, completed pickup, categories
Readarr0.4.18Test dialog, queue, completed pickup, categories

Including the whole loop end to end: Sonarr searching automatically, through Prowlarr, against nzbfast's own indexer, grabbing the result through nzbfast as its download client, and filing it under the right category. Every file that reached a library was checked byte for byte against the file that was posted.

If something is not right

The manual has more on both APIs, including the phone remotes, post-processing scripts on the SAB_* contract, and importing an existing SABnzbd or NZBGet configuration in one click.