Webhook or Watcher
Choose how CW receives playback activity from your media server.
Use Watcher unless you have a specific reason to use Webhooks.
Watcher is managed in CW. It needs no inbound webhook URL and provides runtime controls.
Use Webhooks when the media server should push events to CW. They also suit reliable existing webhook deployments.
Do NOT use Watcher with remote servers or media servers you do not own.
Watcher continuously polls the media-server API and generates substantially more traffic.
Watcher
Watcher reads playback activity from a configured media server profile.
Use Watcher when
CW can reach the media server API.
The server is local or otherwise under your control.
You do NOT use shared servers
You want the simplest setup.
You need Start, Stop, Reload, or Autostart controls.
You use several source or destination profiles.
How Watcher runs
Each route is one mapping:
source profile → destination profile
CW groups enabled routes by source profile.
For example, these routes share one Plex watcher:
Plex Home → Trakt Personal
Plex Home → SIMKL Personal
Plex Home → MDBList Personal
Plex Home → BingeBase Personal
Each route still has its own destination, filters, and options.
Watcher considerations
CW must stay running.
The media server API must be reachable from CW.
Emby and Jellyfin detection uses session polling.
Continuous polling creates more API traffic than Webhooks.
Stopped Watcher routes process nothing until restarted.
Enable Autostart to resume after a CW restart.
Webhooks
Webhooks let the media server send playback events to a generated CW URL.
Use Webhooks when
The media server can reach the CW URL.
The server or plugin delivers reliable playback events.
You use a remote, shared, or third-party server.
Push delivery is preferred over continuous monitoring.
A trusted reverse proxy provides a stable endpoint.
You need a provider-specific webhook workflow.
How Webhooks run
A media server profile receives one generated endpoint URL.
That profile can forward events to one or more tracker destinations.
CW shows each destination as a separate card. The source uses one shared endpoint URL.
Webhook considerations
The URL must be reachable from the media server.
localhostpoints to the media server, not usually CW.Proxies, TLS, firewalls, and container networking can block delivery.
Media servers may reject self-signed certificates.
Regenerating the URL immediately invalidates the previous URL.
Source-profile filters and options affect every attached destination.
Network direction
Watcher: CW → media server
Webhooks: media server → CW
Runtime management
Watcher provides Start, Stop, Reload, Autostart, and route status.
Webhooks have no separate runtime service. They activate with a valid source, destination, and endpoint.
Filtering scope
Watcher filters are stored per route.
Webhook filters are stored per source profile. They affect every attached destination.
Per-destination behavior
Watcher supports route-specific filters, watchlist removal, watched thresholds, final-stop trust, and Plex ratings URLs.
Webhook playback options are shared by source profile. Mappings can still use different tracker profiles.
External requirements
Watcher needs no inbound URL or media server webhook feature.
Webhooks require a media server webhook feature or plugin. Availability and licensing differ by provider.
Can both be enabled?
Yes. Watcher and Webhooks can run together.
Do not send the same source playback to the same tracker profile through both methods.
Related pages
Last updated
Was this helpful?