> For the complete documentation index, see [llms.txt](https://wiki.crosswatch.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.crosswatch.app/crosswatch/settings/scrobbler/webhook-or-watcher.md). # 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. {% hint style="danger" %} 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. {% endhint %} ### 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. * `localhost` points 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. {% hint style="warning" %} Do not send the same source playback to the same tracker profile through both methods. {% endhint %} ### Related pages * [Scrobbler](/crosswatch/settings/scrobbler.md) * [Webhooks](/crosswatch/settings/scrobbler/webhooks.md) * [Watcher](/crosswatch/settings/scrobbler/watcher.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://wiki.crosswatch.app/crosswatch/settings/scrobbler/webhook-or-watcher.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.