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. 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.

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. Nothing is stored: there are no settings to fill in, no credentials kept on file, and no connection to test.

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.

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.
• 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.

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