Why is my seerr widget not showing anything

[BarryV2021]

Description

Seerr Widget not showing anything while 4 movies were request, approved and are now available. It is showing only zero's. While the old Overseerr is showing the correct numbers. There is no API error

homepage version

v1.11.0

Installation method

Docker

Configuration

- Seerr (NAS):
        icon: seerr.png
        href: http://xxx.xxx.xxx.xx:5057/
        description: Media requests
        widget:
          type: seerr
          fields: ["pending", "approved", "processing", "available"]
          url: http://xxx.xxx.xxx.xx:5057
          key: MTc3MzQyOTA3MjQyMTk0NTNlMWI0LTBiNDgtNGEzYy1iNTBhLTczYmEyZGFiZDIzQW== (<- not the real key)

Container Logs

No response

Browser Logs

No response

Troubleshooting

none

Troubleshooting

none

Please do the troubleshooting steps and post the output as requested, particularly the last step may be helpful here. The widget quite literally hasn’t changed, it was just moved.

[BarryV2021]

Hi,

1. URL not ended with a /
2. Service has an unique name called Seerr (NAS)
3. docker exec homepage ping SERVICEIPORDOMAIN -> result 64 bytes from SERVICEIPORDOMAIN icmp_seq=1 ttl=64 time=0.220 ms
4. the command curl -L -k http://192.168.178.31:5057/admin/api.php give a lot of text in the ssh terminal what information do you need?

Im running Overseerr, Jellyseerr and Seerr als a stack in Container Station on a QNAP NAS. Both the Overseerr and Jellyseerr widgets provide the correct information. Information of the first image should be represented by the widget on the homepage.

QNAP NAS

[shamoon]

We would be looking to see the actual output from that last step, feel free to redact anything you think is private. But I would start by re-creating (not just restarting) the relevant containers and stripping things back. Again, the "seerr" widget is literally the same as the old overseerr and the overseerr widget is now an alias to it, so something doesnt add up here, though Im not seeing it at the moment

[BarryV2021]

I have deleted the container and all the config files and rebuild the container and reconfigured it. Then when I requested a movie it showed in the homepage widget 1 approved and 1 processing. After downloading the movie became available in Radarr and Plex and all the digits in the widget on homepage return to 0. So 0 Pending, 0 approved, 0 available and 0 pending. So don't understand how that can be a configuration or connection issue on my side. Maybe a bug in Seerr?

[shamoon]

Again, posting the api output might clarify. the ”new” widget should work the same as before

[BarryV2021]

I tried to find a way to produce the api output on my qnap nas but so far i didn't find a working solution

[BarryV2021]

Installed Seerr on a test RPI and it gives the same issue after a movie was downloaded. This is the file that I created with command curl -L -k http://192.168.178.xxx:5055/admin/api.php. Is this what you needed?
resultaat.json

[buffaloexpatbill]

From what I can see in the src of that widget, don't we want to see a curl something like:

curl -L http://192.168.178.31:5057/api/v1/{endpoint}
?
I was having a little more trouble confirming the actual endpoints at a glance.
For what it's worth, I omitted the -k for curl since this is an http not https.

[shamoon]

Sorry yes I didnt read the above post as literal as you, the "curl the API step" is different for each widget and you have to look at the source code to figure out what its returning. You can also look at the network tab in your browser for the calls to the homepage API (which is what calls the seerr api).

But this is true, for seerr it would be e.g.

homepage/src/widgets/seerr/widget.js

Line 4 in a4e29bc

api: "{url}/api/v1/{endpoint}",

&

homepage/src/widgets/seerr/widget.js

Line 9 in a4e29bc

endpoint: "request/count",

/

homepage/src/widgets/seerr/widget.js

Line 13 in a4e29bc

endpoint: "issue/count",

[BarryV2021]

curl -L http://192.168.178.xxx:5055/api/v1/issue/count -o issues.json -> result = {"message":"cookie 'connect.sid' required","errors":[{"path":"/api/v1/issue/count","message":"cookie 'connect.sid' required"}]}

curl -L http://192.168.178.xxx:5055/api/v1/request/count -o resultaat.json -> result = {"message":"cookie 'connect.sid' required","errors":[{"path":"/api/v1/request/count","message":"cookie 'connect.sid' required"}]}

[buffaloexpatbill]

@shamoon I'd looked though the supplied resultaat.json and found it was HTML for a whole page before commenting.
@BarryV2021 I don't have Seer installed, but it looks like the request needs to be more like this to supply your authentication in a header:
curl -X GET "http://[YOUR_IP]:5055/api/v1/request/count](http://192.168.178.xxx:5055/api/v1/request/count)"
-H "accept: application/json"
-H "X-Api-Key: YOUR_API_KEY_HERE"

Substituting your API key, of course. The responses you got are because it was not authenticated.

[shamoon]

Thanks for helping!

[buffaloexpatbill]

I've spent many years in support and do some coding as a hobby. Been using Homepage in my home lab/lan for a while now. Happy to help where I can, but not much experience with the next.js/javascript specifically.

[BarryV2021]

Thx for the help. I entered this command line:
curl -i -X GET "http://192.168.178.xxx:5055/api/v1/request/count" -H "accept: application/json" -H "X-Api-Key: MY_API_KEY" and got this result:

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 109
ETag: W/"6d-2M4LDLkSRfuAA9tLKWx2wTOwsjI"
Date: Tue, 17 Mar 2026 00:06:20 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{"total":1,"movie":1,"tv":0,"pending":0,"approved":0,"declined":0,"processing":0,"available":0,"completed":1}.

So I requested 1 movie and it was pending and processed. Now it is completed and available in Radarr but not available according the api output.

[buffaloexpatbill]

So this is the output homepage would see. The browser developer tab should also allow you to see that. If it doesn't agree with the status in the Seer app, something is wrong on that side (likely in their API, unless there is something environment specific causing the issue on their side).

EDIT: One other thought occurred to me. If there is more than one user in your environment, this could be a user specific API Key with user specific output.