Media Requests

The Media Requests page brings the request queues from every Seerr and Ombi instance on your server into a single, poster-first view. You can see what has been requested, filter and search across all of them at once, and approve or deny a request without opening each request manager separately.

The page needs no setup to work. It discovers the request managers already installed through QuickBox and reads their queues on demand — there is no base URL to enter, no API key to paste, and nothing to keep in sync. A server administrator can optionally override a provider’s key or address, tune the default view, or turn the feature off, but none of that is required to get started.

Overview

Where to find it

Navigate to Streaming Dashboard > Control Center > Media Requests in the sidebar, or follow the Requests link in the Control Center’s tab bar, past the separator on the right.

Media Requests does not open as one of the Control Center’s four tabs — Overview, Server Users, Devices, and History & Analytics. Like the Media Portal, it opens on the full-width media canvas instead, which is why its link carries an outbound arrow.

All five of those neighbours are administrator-only and require the Streaming Dashboard. Media Requests is the exception on both counts: it needs neither a media server nor the Streaming Dashboard, and it is granted, so an administrator can assign it to a specific person, and that person then finds it in the same place without any of the admin entries coming with it.

When the Streaming Dashboard is switched off

Media Requests does not depend on the Streaming Dashboard, and it does not depend on a media server being installed. It is gated on your permission and nothing else.

So if WSDashboard is turned off in Settings > General > Feature Flags — or no media server is installed, which counts the same way — the other Control Center entries disappear, and Media Requests stays exactly where it is. The “Streaming Dashboard” and “Control Center” headings above it remain visible, but become plain labels rather than links, because the landing pages behind them are part of the feature that is switched off. Anyone granted access always finds Media Requests in the same place.

How discovery works

When you open the page, the dashboard looks at which request managers are installed through QuickBox, works out where each one is running, and reads its request queue directly, using the app’s own key. By default nothing is stored — there are no settings to fill in, no credentials kept on file, and no connection to test. An administrator can optionally store a box-level key or address override; see Settings.

Because discovery reads the live install each time:

• There is no configuration step. You never enter a base URL or an API key.
• A key you regenerate inside Seerr or Ombi is picked up automatically.
• Ports are read from each install as it actually runs, so a request manager on any assigned port is found without you telling the dashboard where it is.

Who sees what

Two permissions govern this page. Both are granted through a role, under the Media Requests permission group in Roles & Permissions. A server administrator holds both inherently.

Seeing or acting across other users stays with server administrators and is deliberately not delegable through the grant — so opening this page to one person never exposes anyone else’s queue. A request for a scope you are not entitled to is refused outright rather than quietly narrowed, so the boundary is always clear. The buttons follow the same rule: approve and deny only appear where you are actually allowed to use them.

Settings

Media Requests works with no configuration — auto-discovery reads each installed request manager on its own. A server administrator can optionally fine-tune it from the Media Requests section of the Streaming Dashboard settings.

Where to configure it

There are two ways in, both for a server administrator:

• The settings cog on the Media Requests page opens the settings in place, scrolled straight to the Media Requests section, without leaving the page.
• The Streaming Dashboard Settings flyout, where Media Requests sits alongside the other streaming settings.

The section only appears when at least one request manager is installed on the server, and each provider block appears only for the provider that is actually installed.

Turning the feature on or off

A master Enable Media Requests switch is the feature’s kill switch. Turned off, the page and its queues are hidden for everyone, grantees included; the provider settings stay readable but inert until it is turned back on.

Per-provider settings

Each installed provider — Seerr and Ombi — gets its own block:

• Enable — include or exclude that provider’s requests.
• API Key Override — see API keys below.
• Linkback URL — a public, browser-reachable base address used to build the deep link that opens a request in the provider’s own web interface.
• External URL — a dial address for an install that auto-discovery cannot reach on its own.
• Installed for — the block names the QuickBox user who owns that install, so an administrator can see whose request manager each setting applies to. The same owner line also appears on the Emby, Jellyfin, and Plex media-server sections.

Display options

• Default View — which tab the list opens on: All requests, Pending, or Approved. The default is All requests, so the full history is shown out of the box.
• In-Library Page Size — how many already-in-library items the list shows per page, between 6 and 100 (default 24).

API keys

By default the dashboard auto-discovers each provider’s API key from the install on disk, per user — the provider block shows an Auto badge and there is nothing to enter. An administrator can instead set a single box-level key that overrides every instance of that provider, at which point the block shows a Manual key badge.

The key field is write-only and masked: the stored key is never sent back to the browser, so you type a new value to replace it and the field never displays what is saved. Clear removes the override and returns that provider to per-user auto-discovery. An administrator can reveal the effective key on demand — a separate, read-only look that is limited to server administrators; the revealed value shows only while the panel is open and is never turned into a stored override.

Using the page

The request canvas

Requests are shown as artwork. Each card carries its poster, title, media type, requester, request manager, and current status.

• Hero — The request that most needs attention is promoted to a banner at the top, with its backdrop, poster, and decision buttons. It is picked from whatever is currently in view, so filtering or switching scope can change it — and it sits above both view modes, not just one.
• View modes — Shelves sorts every request in view into rows by state, the promoted one included, so the hero also appears as a card in its own row. Grid lays every request out together in one continuous grid. A density control sets how large the posters are, and your choice is remembered for your account across sessions and devices.
• Scope toggle — Administrators get an Everyone / Mine switch and start on Everyone. Someone with a grant but no admin level sees only their own requests and gets no toggle, because there is no other scope available to them.
• Search — Search by title or requester. Filtering runs over the requests already loaded, so it is instant.
• Filters — Narrow by Status, Type (Movies or TV), request manager (Seerr or Ombi), and requester. Each filter only offers values actually present in the current view, so it never presents a dead option. The count shows how many requests you are seeing against the total.
• Refresh — Reload the queues on demand. The list also refreshes roughly once a minute on its own.

Statuses

Whether something is available is tracked separately from whether it was decided, so an approved request that has not landed yet and one that is ready to watch are never confused for each other.

The request detail page

Opening a request gives it its own page, with the synopsis, cast portraits, genres, runtime, and rating alongside the request’s own details — status, type, request manager, requester, instance owner, and request and update times. A series additionally gets a per-season table showing what was asked for and what has arrived.

Approving and denying

• Approve forwards the request downstream exactly as approving it inside the request manager would.
• Deny asks twice. It is the one action here that cannot be undone from this page, and on a shelf of posters the button sits under a cursor that is already moving.
• Approve and deny only appear when the request manager itself says the action is still possible — so a request already decided inside Seerr or Ombi does not offer you a button that would fail.
• A denial reason is offered only where it can be kept. Denying an Ombi request gives you an Add a reason for denying field, and Ombi records what you write against the request so the requester can see why. Seerr has nowhere to store a reason, so denying a Seerr request offers no reason field at all — the decision is recorded without one.
• Whether the item is 4K is resolved from the request manager before anything is acted on, never taken from the page.

When a request manager cannot be read

If an instance is stopped, unreachable, or its key cannot be read, the page shows a notice saying so and lists everything it could read. This is deliberate: an unreadable instance subtracts its requests from what you see, so the page tells you rather than looking complete. An empty list, likewise, says what it covers rather than claiming nobody has requested anything.

Request history

The dashboard keeps its own record of the requests it has seen. Once it has observed a request, that request stays visible here even after the request manager itself deletes it — fulfilled titles that Seerr or Ombi has cleared out still appear on the Previously requested shelf, marked Fulfilled, as a read-only history rather than an actionable queue.

In-library and Media Portal links

For a fulfilled title that is actually present in a connected media server, the card shows an In-Library indicator and, where the Streaming Dashboard and a media server are available, a link to open it in the Media Portal. The dashboard checks this against your media server directly, so it works independently of the request manager’s own availability scanner. A history row the dashboard cannot match to a library item is still kept and shown as Fulfilled, just without the in-library indicator.

What history can and cannot recover

The dashboard’s history begins the first time it sees a request. From that point on it is complete: every request it observes is kept, so nothing is lost once tracking has started.

Requests that were already deleted before the dashboard began tracking are a different matter, and this is worth understanding:

• Ombi can be set to delete fulfilled requests permanently. Its Auto Delete Available Requests option (in Ombi’s own Settings > General, with a retention period in days) removes a request — its title and all — once it has been available for the configured time. Anything Ombi purged before the dashboard first saw it is gone at the source and cannot be recovered.
• The dashboard accounts for these honestly rather than hiding them. Where it knows only that some earlier requests existed, it shows a small footnote — for example, “3 earlier fulfilled requests predate dashboard tracking — details were purged by Ombi” — instead of blank cards. That count is all that survived the purge; the titles were never available to recover.
• To keep the full history in Ombi itself, turn off Auto Delete Available Requests. With it off, Ombi keeps returning fulfilled requests, and the dashboard tracks each one with its title intact.
• Seerr keeps its request history natively and does not purge fulfilled requests, so Seerr history is not affected by this at all.

What it is (and is not)

The page is a review-and-decide surface over the request managers you already run. Everything a user does to place a request — browsing, discovery, quotas, notifications, and the download automation behind an approval — continues to live in Seerr and Ombi.

Providers

Artwork and titles

Requests are shown with posters, backdrops, and cast portraits. Artwork is served through the dashboard to any signed-in user and is independent of the cover art provider you choose for the rest of the Streaming Dashboard — you do not need to configure anything for it to appear, and changing that preference does not change these images.

Titles are resolved for both request managers. Seerr does not store a title against a request itself, so the dashboard resolves it and remembers the answer.

Best practices

FAQ

Related pages