# AudioBookRequest: a wishlist front end for audiobook servers

> AudioBookRequest is a small FastAPI application that gives a Plex, Audiobookshelf or Jellyfin household one place to search Audible and request audiobooks, with Prowlarr for the download, Audiobookshelf for duplicate detection, and three user groups. It is GPL-3.0 licensed, deploys as a single container, and explicitly does not organize files.

**markbeep/AudioBookRequest** — Minimal and lightweight audiobook request management/wishlist for Plex/Audiobookshelf/Jellyfin

- Repository: https://github.com/markbeep/AudioBookRequest
- Website: https://github.com/markbeep/AudioBookRequest/wiki/
- Stars: 717 · Forks: 29
- Language: Python
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/markbeep-audiobookrequest

## One front end for requests, with the downloading left to other tools

AudioBookRequest is a request and wishlist management tool for a Plex, Audiobookshelf or Jellyfin instance. The readme places it in a familiar lineage: if you know Overseer, Ombi or Jellyseer, this is in the same vein, but for audiobooks.

The important framing is in the motivation section. It is not intended as a full replacement for Readarr or Chaptarr, but to be used alongside them. That is a deliberate boundary, and the out of scope section states it as a feature rather than a gap.

The boundary is specific. AudioBookRequest does not handle moving, renaming, or editing metadata after downloads. Instead it exposes multiple REST API endpoints so scripts and other apps can interoperate with it.

So the division of labour is: AudioBookRequest is where people ask for books and where a request becomes a download, and something else in the arr stack does the file organisation. A listed alternative is Listenarr, described as a more all-in-one approach with built-in file organization, and the readme invites issues with other options.

That trade is worth judging on its merits. The lightweight tool does one job well and has a smaller surface to maintain. The all-in-one tool does more for you and takes more responsibility for the library layout. Which is right depends on whether your media library is organised by hand or by an arr tool.

## Search comes from Audible, and duplicates come from Audiobookshelf

The search feature uses the Audible API, which is what makes the request flow work: a user types an author or title, gets Audible results with covers and metadata, and requests one with the plus button. Manual requests are supported for any book not available on Audible, which matters for the long tail of titles that never made it to Audible.

Audiobookshelf integration is the more interesting of the two integrations, and it does two things. It checks whether a book already exists in your Audiobookshelf library and marks it as downloaded in the search results, so you do not request something you already have. And when a request is marked as downloaded in AudioBookRequest, it triggers a library scan in Audiobookshelf so the new item appears quickly rather than waiting for the automatic detection.

The setup is an API token for an account with access to your audiobook library, an admin account recommended, the base URL of the server, the target library, and a toggle for using Audiobookshelf to mark existing books as downloaded.

The documentation is candid about the matching. AudioBookRequest searches Audiobookshelf by ASIN and by title plus first author, and it says plainly that this is a best-effort match which may not catch every case depending on your metadata. That is a real limitation for a duplicate prevention feature, since a miss means a user requests a book they already own.

Auto download is the third piece, and it is the Prowlarr integration. It is enabled for requests from Trusted and Admin users, so a normal user request waits for approval while a trusted user's request starts downloading immediately. The Prowlarr side is configured with an API key and a base URL, and the download settings include heuristics that rank the sources Prowlarr returns, plus indexer flags for prioritising particular sources.

## Deploying is one container with a config directory

The quick start is a single docker run:

```bash
docker run -p 8000:8000 -v $(pwd)/config:/config markbeep/audiobookrequest:1
```

Then you open http://localhost:8000. The volume mount is not optional in practice: the project uses the /config directory inside the container for storing configs and data, and mounting it locally is what makes the data survive a restart.

The stated goal is that you can deploy and create your first requests in under five minutes, and the deployment target is Docker or Kubernetes. For bare metal, the documentation points to a local development page in the wiki.

The compose file shows a fuller local stack with three services. A web service built from the local context with a config volume and port 8000 published, which sits behind a local profile so it does not start by default. A gotify service on the public server image with its data volume and port 8080, which is there to exercise the notification path. And a psql service on postgres:17 with a named user, password and database, published on 5432.

The database choice is genuinely optional. Both SQLite and Postgres are supported, and the dependency list carries psycopg2-binary alongside the SQLAlchemy-family stack, so Postgres is a first-class option rather than an afterthought.

The stack itself is modern Python. The project requires Python 3.14 or newer and the dependencies are pinned to recent versions, including fastapi with the standard extra, sqlmodel with pydantic, apscheduler for scheduled jobs, alembic for migrations, argon2-cffi for password hashing, structlog for logging, torf and torrent-parser for handling torrent metadata, and terminaltables, which is a telling dependency: it renders the search results as text tables in a terminal, so the tool has a command line side as well as a web interface.

## The Dockerfile builds the CSS in a separate stage

The container image is a three stage build, and the first stage is the interesting one because it runs a CSS toolchain rather than Python.

The css stage starts from alpine:3.23, installs curl and build-base, and then decides which Tailwind binary to download based on the architecture, mapping x86_64 to x64 and aarch64 to arm64, and failing with an unsupported architecture message for anything else. It downloads a pinned Tailwind release, 4.1.18, adds the DaisyUI module and its theme module into the static directory, copies the templates and the Tailwind input, and compiles it to a minified globals.css.

The python-deps stage uses uv on a Python 3.14 alpine image, copies the lock file and pyproject, syncs dependencies with the lock honoured and no dev extras, then runs a project script, app/util/fetch_js.py, which fetches JavaScript into the static directory.

The final stage is a plain Python 3.14 alpine image that copies the compiled CSS, the virtual environment, the static directory, the templates, the application code and the alembic migration setup. The startup command is worth reading closely, because it runs the database migration before the server:

```bash
CMD /app/.venv/bin/alembic upgrade heads && /app/.venv/bin/fastapi run --port $ABR_APP__PORT --proxy-headers --forwarded-allow-ips="${ABR_APP__FORWARDED_ALLOW_IPS:-127.0.0.1}"
```

Alembic runs to the head revision on every start, and the server runs with proxy headers enabled and a forwarded allow list defaulting to localhost. The port and version are passed as environment variables, ABR_APP__PORT and ABR_APP__VERSION, which is the nested settings style the project uses throughout.

The frontend is deliberately light. The readme advertises a lightweight website with no bulky javascript files so it works on low bandwidth, and a mobile friendly interface for searching and accepting requests on the go, which is a sensible constraint when the users are family members on phone connections.

## Three user groups, OIDC, and a lockout to understand before you enable it

The user model is minimal by design, and the documentation says so plainly: only three assignable groups, made to get out of your way. The permissions that matter are Trusted and Admin, and Trusted is what auto download keys off.

The first run is a special case. When you log in the first time, the login type and the root admin user have to be configured, and that first step cannot be repeated casually. The readme has a dedicated section on getting locked out, which tells you how seriously the project takes this.

OpenID Connect is supported and documented on its own wiki page, where you set up OIDC authentication with your favourite auth provider. For a home server that already runs an identity provider, that is the way to avoid handing out local passwords, and it is also the way to give your household accounts without managing them in the app.

Notifications go out to whatever service you already use. The feature list names apprise, gotify, discord and ntfy, and the compose file includes a gotify service specifically so the notification path is exercised in development. That is a broad list, and it matters more than it looks: a request that nobody is told about is a request that does not get approved.

The other thing in the feature list is a deliberate omission with a purpose. AudioBookRequest does not handle moving, renaming, or editing metadata after downloads, but it does expose multiple REST API endpoints for interoperability with scripts and other apps. So the file organisation problem is not ignored, it is delegated, and the API is the seam where the tool that does that work plugs in.

## Conclusion

AudioBookRequest suits a household or small group running a media server who wants a shared wishlist with automatic downloads and notifications, and who is comfortable with Docker and a Prowlarr instance. It does not suit anyone expecting it to organise files, since the project states it does not move, rename or edit metadata after downloads, and it is not a Readarr replacement. Before deploying, run the container with the config directory mounted, set the database to SQLite or Postgres, and read the environment variables page in the wiki, because the first login fixes the root admin and cannot be done from the interface.

## FAQ

### What is AudioBookRequest and what does it do?

It is a minimal, lightweight tool for managing audiobook requests on a Plex, Audiobookshelf or Jellyfin instance. It uses the Audible API to search for books, lets any user request them, and can hand the request to Prowlarr for automatic downloading.

### How do I deploy AudioBookRequest?

The quick start runs the image with docker run -p 8000:8000 -v $(pwd)/config:/config markbeep/audiobookrequest:1 and then you open http://localhost:8000. The /config directory holds configs and data, so mounting it locally is what keeps data across restarts. Docker or Kubernetes is the intended deployment path.

### Does AudioBookRequest organize and rename my audiobooks?

No. The project states it does not handle moving, renaming, or editing metadata after downloads, and it is not intended as a full replacement for Readarr or Chaptarr. It exposes REST API endpoints instead so other apps and scripts can do that work.

### How does the Audiobookshelf integration work?

It checks whether a book already exists in your Audiobookshelf library and marks it as downloaded in search results to avoid duplicate requests, and it triggers a library scan in Audiobookshelf when a request is marked as downloaded. The match is by ASIN and by title plus first author, which the documentation calls a best-effort match.

### Which databases does AudioBookRequest support?

Both SQLite and Postgres are supported. The dependency list includes psycopg2-binary, and the compose file includes a psql service on postgres:17 alongside the web service.

## Sources

- [License: GPL-3.0](https://github.com/markbeep/AudioBookRequest/blob/main/LICENSE)
- [markbeep/AudioBookRequest on GitHub](https://github.com/markbeep/AudioBookRequest)
- [Project website](https://github.com/markbeep/AudioBookRequest/wiki/)
- [README](https://github.com/markbeep/AudioBookRequest/blob/main/README.md)
- [Releases](https://github.com/markbeep/AudioBookRequest/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/markbeep-audiobookrequest