enoch85 · Sep 28, 2026 · Sep 28, 2026 · Sep 28, 2026
diff --git a/AGENTS.md b/AGENTS.md
@@ -36,7 +36,9 @@ Maintainerr's `HEAD`. These rules are hard rules when you open the PR for one.
   release. No speculative additions and no broad rewrites.
 - **Doc-only changes.** Restrict edits to `docs/` and `static/openapi-spec/`. Do
   not touch sidebars, config, or unrelated assets unless a doc edit strictly
-  requires it.
+  requires it. A new page under `docs/api/` does require one line in
+  `sidebars.js`, because without it the page has no route into the site. Add it
+  and say so in the PR description.
 - **Keep the PR tied to the code diff**, not to the issue summary alone.
 - **Structure the PR description** in two parts:
   1. **What was added**, one short bullet per doc edit, citing the upstream

diff --git a/docs/API.md b/docs/API.md
@@ -13,13 +13,13 @@ hide:
 
 :::
 
-Maintainerr exposes 219 HTTP endpoints. Every one of them is documented in the pages below, grouped by area.
+Maintainerr exposes 226 HTTP endpoints. Every one of them is documented in the pages below, grouped by area.
 
 ## Endpoints by area
 
 | Page                                                          | Endpoints | Covers                                                                             |
 | ------------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------- |
-| [Settings](./api/settings.md)                                 | 74        | Every integration's connection settings, connection tests, the media server switch |
+| [Settings](./api/settings.md)                                 | 78        | Every integration's connection settings, connection tests, the media server switch |
 | [Rules](./api/rules.md)                                       | 29        | Rule groups, execution, exclusions, community rules, YAML import and export        |
 | [Overlays](./api/overlays.md)                                 | 28        | Overlay settings, processing runs, templates, fonts and images                     |
 | [Collections](./api/collections.md)                           | 25        | Collections, membership, bulk media actions, handling, posters, logs               |
@@ -31,6 +31,8 @@ Maintainerr exposes 219 HTTP endpoints. Every one of them is documented in the p
 | [Metadata, storage and events](./api/metadata-and-storage.md) | 6         | Metadata provider lookups, storage metrics, the events stream                      |
 | [Servarr](./api/servarr.md)                                   | 5         | Radarr, Sonarr and Sportarr disk space and quality profiles                        |
 | [Streamystats](./api/streamystats.md)                         | 2         | Streamystats server info and per-item watch statistics                             |
+| [Watch statistics](./api/watch-statistics.md)                 | 2         | Per-item Tautulli and Tracearr watch statistics                                    |
+| [Ombi](./api/ombi.md)                                         | 1         | Ombi requester names                                                               |
 
 ## API conventions
 
@@ -66,7 +68,7 @@ Bodies are validated per endpoint. Where a schema exists, a failure returns:
 
 `errors` holds the individual validation problems.
 
-Validation is not universal. Of the 70 endpoints that take a body, **17 have no schema at all**, so the body reaches the service unchecked. Each of those 17 says so on its own entry. Most numeric path parameters are checked and reject a non-numeric value with a `400` before the handler runs, but not all: `DELETE /api/notifications/configuration/{id}` declares a numeric id without that check.
+Validation is not universal. Of the 72 endpoints that take a body, **17 have no schema at all**, so the body reaches the service unchecked. Each of those 17 says so on its own entry. Most numeric path parameters are checked and reject a non-numeric value with a `400` before the handler runs, but not all: `DELETE /api/notifications/configuration/{id}` declares a numeric id without that check.
 
 ### Success and failure in the same status code
 

diff --git a/docs/Collections.md b/docs/Collections.md
@@ -34,9 +34,9 @@ When Plex is your configured media server, the rule group or collection form can
 
 - This is a Plex-only feature. Jellyfin and Emby do not expose a safe collection reorder API, so the sort control is not available there.
 - `Default (no custom sort)` leaves the collection order alone.
-- The options are delete soonest or latest, title, air date or release date, rating, and watch count.
+- The options are delete soonest or latest, title, date added, air date or release date, rating, and watch count. `Date Added` is the date the item was added to your media server, which is the same order the server itself uses.
 - Saving a new or changed sort applies it to Plex immediately; you do not need to wait for the next collection add cycle.
-- Air date / release date, rating, watch count, and delete soonest / latest sorts break ties by title so Plex keeps the same order you see in Maintainerr.
+- Air date / release date, date added, rating, watch count, and delete soonest / latest sorts break ties by title so Plex keeps the same order you see in Maintainerr.
 
 :::note
 Turning the custom sort back off does not restore Plex's previous order automatically. If you want the old order back, change it directly in Plex.

diff --git a/docs/Configuration.md b/docs/Configuration.md
@@ -9,6 +9,8 @@ All configuration is done inside the application. No extra config files are requ
 
 When you first access the web UI, you should be redirected to the settings page. If that does not happen, try refreshing the page.
 
+Service connections live under `Services` in the sidebar. That page lists every service as a card, grouped by what it does - media server, requests, library managers, metadata, watch statistics, downloads and notifications - and each card says whether that service is set up. Open a card to configure it, then use the row of logos along the top of the page to move between services. `Settings` holds the rest: `General`, `Logs`, `Jobs` and `About`. A `/settings/<service>` link lands on the same page under `/services`.
+
 :::note Service URLs
 Every service URL field expects a base URL starting with `http://` or `https://`. Any trailing slashes are removed for you when you save or test the setting.
 :::
@@ -29,7 +31,7 @@ These settings are OK for most installations.
 
 ## Media Server
 
-You need to configure one media server: Plex, Jellyfin, or Emby. Multiple media servers are not supported simultaneously.
+You need to configure one media server: Plex, Jellyfin, or Emby. Multiple media servers are not supported simultaneously. Pick it on the media server card under `Services`; that page also holds its connection settings.
 
 ## Plex
 
@@ -111,7 +113,7 @@ Jellyfin can also be used as your media server connection.
 Streamystats is only available for Jellyfin users
 :::
 
-The separate `Settings -> Streamystats` page only appears when Jellyfin is the active media server. Maintainerr reuses your saved Jellyfin API key for authentication, so you only need to provide the Streamystats base URL.
+The `Services -> Streamystats` page only appears when Jellyfin is the active media server. Maintainerr reuses your saved Jellyfin API key for authentication, so you only need to provide the Streamystats base URL.
 
 | Setting | Description                                                                                                       |
 | ------- | ----------------------------------------------------------------------------------------------------------------- |
@@ -136,33 +138,44 @@ Seerr configuration is required if you want to use Seerr-related rule parameters
 | URL     | The domain name or local IP address of the host running Seerr |
 | API key | The API key from Seerr settings                               |
 
+## Ombi
+
+Ombi is a second request service alongside Seerr. Both can be configured at once. Ombi's configuration is required if you want to use Ombi-related rule parameters, remove Ombi requests, or see who requested media in pre-deletion notifications.
+
+| Setting | Description                                                  |
+| ------- | ------------------------------------------------------------ |
+| URL     | The domain name or local IP address of the host running Ombi |
+| API key | The API key from Ombi, under `Settings`, `Ombi`, `API Key`   |
+
+Ombi holds one request per movie, and one request per user for a show, each covering the seasons and episodes that user asked for. That shapes what the rule properties answer, so read the [Ombi rules](./Glossary.md#ombi) in the glossary before you build a rule on them.
+
+Once a request has gone available, Ombi never lists it as unavailable again. If you want the request removed when Maintainerr deletes the media, turn on `Force delete Ombi request` on the rule group - see [Creating rules](./Rules.mdx#general).
+
 ## Radarr
 
 Radarr's configuration is required to use its parameters in rules and to remove or unmonitor movies.
 
-:::note
-Enter the `Base URL` for Radarr and Sonarr without a leading slash - `radarr`, not `/radarr`.
-:::
+Each Radarr instance is its own card on the page. Use `Add Radarr server` to add another.
 
-| Setting        | Description                                                    |
-| -------------- | -------------------------------------------------------------- |
-| Server Name    | A friendly name to help identify the server                    |
-| Hostname or IP | The domain name or local IP address of the host running Radarr |
-| Port           | The port Radarr runs on                                        |
-| Base URL       | The URL base configured in Radarr, if one is set               |
-| API key        | The API key from Radarr settings                               |
+| Setting     | Description                                                                                          |
+| ----------- | ---------------------------------------------------------------------------------------------------- |
+| Server Name | A friendly name to help identify the server                                                          |
+| URL         | The base URL of the Radarr instance, such as `http://localhost:7878` or `https://radarr.example.com` |
+| Base Path   | The URL base configured in Radarr, if one is set. Only editable once `URL` holds a complete address  |
+| API key     | The API key from Radarr settings                                                                     |
 
 ## Sonarr
 
 Sonarr's configuration is required to use its parameters in rules and to remove or unmonitor shows.
 
-| Setting        | Description                                                    |
-| -------------- | -------------------------------------------------------------- |
-| Server Name    | A friendly name to help identify the server                    |
-| Hostname or IP | The domain name or local IP address of the host running Sonarr |
-| Port           | The port Sonarr runs on                                        |
-| Base URL       | The URL base configured in Sonarr, if one is set               |
-| API key        | The API key from Sonarr settings                               |
+Each Sonarr instance is its own card on the page. Use `Add Sonarr server` to add another.
+
+| Setting     | Description                                                                                          |
+| ----------- | ---------------------------------------------------------------------------------------------------- |
+| Server Name | A friendly name to help identify the server                                                          |
+| URL         | The base URL of the Sonarr instance, such as `http://localhost:8989` or `https://sonarr.example.com` |
+| Base Path   | The URL base configured in Sonarr, if one is set. Only editable once `URL` holds a complete address  |
+| API key     | The API key from Sonarr settings                                                                     |
 
 ## Sportarr
 
@@ -176,21 +189,22 @@ shows come from the configured Sportarr connection. For a league none of your co
 Maintainerr can read that artwork from sportarr.net instead, which is off unless you set the
 `SPORTARR_NET` environment variable to `on`. Nothing is requested from sportarr.net otherwise.
 
-Artwork and descriptions are cached. `Refresh Metadata` in the Sportarr server dialog drops that
+Artwork and descriptions are cached. `Refresh metadata` on the Sportarr server card drops that
 cache, so the next view fetches them again.
 
-| Setting     | Description                                 |
-| ----------- | ------------------------------------------- |
-| Server Name | A friendly name to help identify the server |
-| URL         | The base URL of the Sportarr instance       |
-| API key     | The API key from Sportarr settings          |
+| Setting     | Description                                                                                           |
+| ----------- | ----------------------------------------------------------------------------------------------------- |
+| Server Name | A friendly name to help identify the server                                                           |
+| URL         | The base URL of the Sportarr instance                                                                 |
+| Base Path   | The URL base configured in Sportarr, if one is set. Only editable once `URL` holds a complete address |
+| API key     | The API key from Sportarr settings                                                                    |
 
 ## Exclusion tag
 
 When Maintainerr excludes an item, it can apply a protective tag to the matching Radarr movie or Sonarr series, so the \*arr instance carries a single source of truth for "do not touch". This covers both global and collection-scoped exclusions.
 
 :::note
-The `Exclusion tag` section appears on the `Settings -> Radarr` and `Settings -> Sonarr` pages once that service is configured. Radarr and Sonarr are configured independently: each has its own enable toggle, label, and removal policy.
+These settings sit on each Radarr and Sonarr server's own card, under `Services`. Every server is configured independently, with its own enable toggle, label, and removal policy. A collection-scoped exclusion tags the item on that collection's server only. A global one tags it on every configured server that has tagging switched on and tracks the item, each with that server's own label.
 :::
 
 | Setting                  | Description                                                                                                                                                                                                                                       |
@@ -204,7 +218,7 @@ Tagging is best-effort: the tag is added or removed through the Radarr/Sonarr ed
 ## Download Client
 
 :::note
-The separate `Settings -> Download Client` page only appears once Radarr or Sonarr is configured.
+The `Services -> Download Client` page only appears once Radarr or Sonarr is configured.
 :::
 
 When media is removed through Radarr or Sonarr, Maintainerr can remove the matching completed download (and optionally its data) from your download client. Downloads are matched using the Radarr/Sonarr download history, so media removed without Radarr/Sonarr is left untouched.
@@ -258,7 +272,7 @@ A `403 Forbidden` on the connection test (or in the logs) means qBittorrent acce
 
 ## Metadata
 
-Maintainerr has a separate `Settings -> Metadata` page for poster, backdrop, and metadata-provider settings used across the UI.
+Maintainerr has a `Services -> Metadata` page for poster, backdrop, and metadata-provider settings used across the UI.
 
 This page is mainly useful when you want better artwork fallback, more reliable cross-provider ID resolution, or more control over which metadata source Maintainerr prefers.
 

diff --git a/docs/Glossary.md b/docs/Glossary.md
@@ -2125,6 +2125,92 @@ Indicates whether the media was requested in Seerr.
 
 ---
 
+### Ombi
+
+:::note
+Ombi holds one request per movie, and one request per user for a show, each covering the seasons and episodes that user asked for. A season or episode property therefore answers from the requests that cover it, and a show property from all of them.
+
+:::
+
+#### Requested by user
+
+:::info
+The Ombi username of the user who requested the media. A request made with Ombi's API key is listed under the alias that request carries.
+
+:::
+
+- Key: Ombi.addUser
+- Availability: movies, shows, seasons, episodes
+- Type: text
+
+#### Request date
+
+:::info
+The date when the media was requested in Ombi. Where several requests cover the item, the earliest one.
+
+:::
+
+- Key: Ombi.requestDate
+- Availability: movies, shows, seasons, episodes
+- Type: date
+
+#### Release/air date
+
+:::info
+The release date Ombi holds for the movie or show. For a season or episode it is the earliest air date among the requested episodes, because Ombi only stores air dates for the episodes someone actually requested.
+
+:::
+
+- Key: Ombi.releaseDate
+- Availability: movies, shows, seasons, episodes
+- Type: date
+
+#### Approval date
+
+:::info
+The date when the media request was approved in Ombi. Ombi only stamps an approval that was given by hand, so an auto-approved request answers with its request date instead.
+
+:::
+
+- Key: Ombi.approvalDate
+- Availability: movies, shows, seasons, episodes
+- Type: date
+
+#### Media downloaded date
+
+:::info
+The date when Ombi marked the request as available.
+
+:::
+
+- Key: Ombi.mediaAddedAt
+- Availability: movies, shows, seasons, episodes
+- Type: date
+
+#### Amount of requests
+
+:::info
+The number of Ombi requests covering the media. A movie is always 1 or 0.
+
+:::
+
+- Key: Ombi.amountRequested
+- Availability: movies, shows, seasons, episodes
+- Type: number
+
+#### Requested in Ombi
+
+:::info
+Indicates whether the media was requested in Ombi.
+
+:::
+
+- Key: Ombi.isRequested
+- Availability: movies, shows, seasons, episodes
+- Type: boolean
+
+---
+
 ### Tautulli
 
 :::note

diff --git a/docs/Migration.md b/docs/Migration.md
@@ -41,6 +41,8 @@ The database schema includes support for overlays.
 - a `sportarr_settings` table plus optional Sportarr server and quality-profile fields on collections. Existing collections remain unchanged until you configure Sportarr.
 - a `cleanupLeftoverFolders` collection field for the opt-in leftover-folder cleanup. Existing collections default to disabled.
 - three Tracearr settings (`tracearr_url`, `tracearr_api_key`, `tracearr_server_id`) for the Tracearr watch history integration. Existing configurations are unaffected.
+- two Ombi settings (`ombi_url`, `ombi_api_key`) plus a `forceOmbi` collection field for the Ombi request service. Existing collections default to off, and nothing contacts Ombi until you configure it.
+- a move of the Radarr and Sonarr exclusion-tag settings out of the global settings row and onto each server, as `tagExclusions`, `exclusionTag` and `untagOnUnexclude` columns on `radarr_settings` and `sonarr_settings`. The migration copies each service's settings onto every server of that service, so tagging behaves exactly as it did before the upgrade. Its `down()` does not copy them back.
 
 No manual database work should be required, but you should still keep a backup of `/opt/data/maintainerr.db` before upgrading and allow startup migrations to complete before using the overlay screens.