Every time SABnzbd searches an indexer, something happens in the background that most people never think about. Your downloader sends a plain HTTP request to a URL. The indexer responds with XML. The downloader parses it, shows you results, and eventually fetches an NZB file using the same basic pattern. That whole exchange — the URL shape, the parameters, the XML structure — is Newznab. You've been using it this whole time.
Where it came from
Newznab started as an open-source indexer project — a PHP application you could self-host to run your own private Usenet index. The project itself is mostly defunct now, but the API it defined lived on. Other indexers adopted it, downloaders built against it, and eventually it became a de facto standard through sheer momentum. Nobody ratified it. Nobody maintains a spec document. It won by being first and being simple enough that everyone could implement it.
Today "Newznab-compatible" is a practical guarantee: if your indexer supports the standard and your downloader supports it, they'll talk to each other without any custom integration work. Mix and match freely.
What the API actually looks like
The whole thing runs over plain HTTPS GET requests. Every call goes to the same base path —
typically /api — with a t parameter that specifies the function.
An API key authenticates the request. Responses come back as XML.
That's it. No OAuth, no JSON, no webhooks. Just query strings and XML.
Capabilities
The first thing a downloader usually does when you add a new indexer is call the
caps endpoint — short for capabilities. This returns metadata about the indexer:
its name, what categories it supports, search limits, and feature flags.
GET /api?t=capsThe downloader reads this response to understand what it's working with. No API key required — it's public information.
Search
The search function takes a query and returns a list of matching releases.
GET /api?t=search&q=some+title&apikey=YOUR_KEY&cat=7000
The response is an RSS-like XML feed. Each item describes one release: its name, size, category,
age, and an enclosure URL pointing to the NZB file. Your downloader renders this as search
results. The cat parameter filters by category — which brings us to one of the
quirkier corners of the standard.
The category system
Newznab categories are four-digit integers organised in a rough hierarchy. The thousands digit is the broad type; the rest narrows it down. Some common ones:
1000— Console (games)2000— Movies5000— TV6000— XXX7000— Other
Each top-level category branches into subcategories: 6010 for DVD, 6030
for HD, 6040 for UHD, and so on. Not every indexer uses every subcategory, and the
mapping is loose — which is why the caps response exists. It tells you exactly
which category IDs this particular indexer actually populates.
Fetching an NZB
Once you've found a release you want, your downloader fetches the NZB file through the
get endpoint:
GET /api?t=get&id=RELEASE_ID&apikey=YOUR_KEYThe response is the raw NZB file — an XML document that describes the Usenet articles making up the release. SABnzbd takes this file and queues the download. The indexer's job ends here; everything after this point is between SABnzbd and your Usenet provider.
Why the standard matters
The unsexy answer is: interoperability. Because Newznab is a shared interface, tools like Radarr, Sonarr, Lidarr, and Prowlarr can talk to any compatible indexer without writing custom code for each one. You add an indexer URL and an API key once, and your entire automation stack gains access to it.
From the indexer's side, implementing Newznab means instant compatibility with years of existing tooling. No SDK to distribute, no integration guides to maintain. The protocol is simple enough that a compliant implementation is a few hundred lines of code.
From your side as a user, it means you're never locked in. Swap indexers, switch downloaders, run multiple indexers in parallel through an aggregator like Prowlarr — the standard makes all of it work transparently.
NZBporn and Newznab
NZBporn exposes a fully Newznab-compatible API on top of the prdb.net release catalog. When
you add NZBporn to SABnzbd as a custom indexer, your downloader goes through exactly the flow
described above: it calls caps to discover what NZBporn supports, sends
search requests with your API key, and fetches NZB files through get.
Nothing proprietary, nothing to install. Just the same quiet handshake that's been running the NZB world for over a decade.