Plex uses one webhook for all linked servers, to identify which server send the event we have to parse the payload to extract Server.uuid, which is problematic as there are many ways to send webhook payloads from different server providers. and to link correct event to a server we need a way to identify which server sent the event as early as possible. so my suggestion is to add a request headers
As i mentioned before i am working on a selfhosted watch state sync which rely on many different servers webhooks as its stand right now only plex uses webhooks linked to user account rather then server. if i am running mutli plex servers they are use the same token.
as stands right now i use hacky way of using IPs to link servers.
Indeed that what is happening right now, what i want is the ability to detect the server before having to parse the payload. for other media servers using a unique api key for each server suffice to identify the server. However, Plex uses a unique way of linking web hooks to user account rather then servers, which prevents using unique api key for each plex server.
so what i come up with is use one apikey and filter based on IP, its something but not really good way forward.
So, adding unique identifer to the request headers will help greatly.
I want to be able to identify the server via request headers to link said request to user server. this is not possible unless I parse the payload. I dont want to parse the payload twice just to identify plex server.
my tool works by providing media server specific payload parsers.
each media server has different way of presenting the payload, as such we pass the request to the correct parser, however to know which parser and server the request belong to i need to differentiate between plex servers.
If you do not understand what im saying please take look at how almost all web hooks [emby, jellyfin] etc works and then take look how plex implements web hooks.
Wouldn’t it be better to have separate endpoints on your webhook server to differentiate what the payload is? Normally, the webhook server is the one that dictates what the payload format should be for a specific endpoint.
Using Discord as an example, the base webhook URL is https://discord.com/api/webhooks/<id> and it expects a Discord formatted payload. However, Discord can also accept Slack or Github formatted payloads using https://discord.com/api/webhooks/<id>/slack or https://discord.com/api/webhooks/<id>/github, respectively. The endpoint dictates the payload format so there is no need to figure out how to parse it.
So for your scenario, you would have something along the lines of https://webhook.site/<id>/plex, https://webhook.site/<id>/emby, and https://webhook.site/<id>/jellyfin that dictates the payload format without needing to figure out which parser to use.
Indeed your solution would be great if i was SaaS service, and have predetermined number of supported services, right now i am supporting plex, jellyfin and emby. and soon more, and there will be custom modules that users will create.
The idea of this tool is to be modular and to support as many backends as possible, so at initial stage we decide which module should handle the webhook payload, i need to determine what server this request belong to, to have better understanding of what i mean take look at this code.
First step, is to determine what apikey belong to which backend, after that we create the the class and pass request for “that” module to process the payload. this step is necessary to generate
providers ID > internalID for that “specific” server. We only deal with GUIDs to mark items as watched/unwatched.
Other media servers like emby and jellyfin do not need work around as the server handle the webhook pushing which i can tag with different api key to differentiate what key belong to. However, Plex attach the webhooks to user account NOT server, so it’s necessary to parse the payload to get Server.Uuid and then compare that to stored id.
I mean i can just bite the bullet and do it, however it’s really sad that the webhook feature in plex is in such sad state. Like, you would expect if the user marked an episode/movie as watched/unwatched that would trigger webhook event. but No only if you reach 90% then does it trigger. like im not sure why the restrictions in place while other media servers have better overall handle of that.
Using a single magic API endpoint for all payloads is a path to madness. It’s a false flexibility that counter-intuitively makes services more tightly coupled and brittle.
Yeah, and that’s great - from the perspective of a scrobbling user with access to multiple servers.
Consider supporting Tautulli as an additional or alternative webhook initiator. That can provide more server-centric notifications.
Thanks for your reply mate, I dont think having many endpoints will solve the problem to begin with, and the serveHttpRequest do so little it wont make difference if i had 1 endpoint or millions of endpoint the underlying problem still the same. lets say i have /plex endpoint for sake of argument, which what the apikey already references, i still need to pre check the content for server id. so having many different endpoints still leaves us having to process the request twice.
Yeah, and that’s great - from the perspective of a scrobbling user with access to multiple servers.
I can agree that having it attached to user account can be useful IF you can specify what webhook goes to what server i.e.
Plex Webhook page > add [Choose Servername , and url] that would make more sense than one global webhook.
Anyway i won’t argue this further it was an idea that i had, but clearly i am unable to communicate it better.
