> 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/synchronization/trackers/wetrakr.md).
# WeTrakr
WeTrakr adapter notes for syncing watchlist, history, ratings, and playback progress.
#### What it supports
| Feature | Media types | Operations |
| ------------------------ | -------------------------------- | ---------------------------------------------- |
| Watchlist | Movies, shows | Read, add, remove |
| History | Movies, episodes | Read, mark watched, remove; optional rewatches |
| Ratings | Movies, shows, seasons, episodes | Read, add, update, remove |
| Progress | Movies, episodes | Read, update; removal has limitations |
| Collections | — | Not supported |
| Playlists / custom lists | — | Not supported |
Ratings use a **1–10** scale. Available pair features also depend on what the other provider supports.
{% hint style="info" %}
Connect your account first: [WeTrakr](/crosswatch/settings/connections/trackers/wetrakr.md). Select the correct connection profile when creating the sync pair.
{% endhint %}
#### How matching works
CrossWatch uses **TMDb**, **IMDb**, and **TVDb** IDs, plus native WeTrakr IDs returned by the API.
Episode matching also uses the parent show IDs and season/episode numbers. Season ratings require the parent show and season number. Missing or unresolved IDs are reported in the sync results.
Progress writes require external IDs; a native WeTrakr ID alone is not enough.
#### Watchlist behavior
* Maps the CrossWatch watchlist to WeTrakr's **planning** status.
* Reads, adds, and removes movies and shows.
* Uses activity timestamps and incremental reads when possible, with full reads when needed to detect removals.
#### Ratings behavior
* Reads movie, show, season, and episode ratings.
* Supports new ratings, rating updates, and removing ratings.
* Reads each media type separately and verifies writes against the returned ratings.
#### History behavior
* Syncs watched movies and individual episodes, including available watch dates.
* With **Rewatches** disabled, syncs watched state rather than individual plays.
* With **Rewatches** enabled in the pair's History settings, syncs individual watch events and can remove a specific play.
* Rewatches are off by default and do **not** require WeTrakr VIP. The other provider must also support them and may have its own account requirements.
#### Progress behavior
* Syncs unfinished movie and episode playback positions.
* Skips changes that would overwrite active playback or newer target progress.
* Writes resume positions without marking the title watched.
* Handles ignored API responses as skipped operations instead of reporting them as applied.
#### Settings (advanced)
Configure the direction, connection profiles, enabled features, removal behavior, and optional rewatches on the pair under **Synchronization**. Dry runs preview changes without writing them.
Activity checks and journal use
Watchlist, history, and ratings use `/sync/last_activities` to decide whether cached data can be reused. When safe, `from_date` reads fetch changes since the previous checkpoint.
The journal is used selectively for history removals when rewatches are enabled and it reduces requests. CrossWatch checks the result and falls back to a full read when the journal is incomplete or inconsistent. Watchlist, ratings, and progress do not poll the journal.
Endpoints used
* Watchlist: `GET /sync/tracking/planning/{movies|shows}`
* Watched state: `GET /sync/tracking/watched/{movies|episodes}`
* Individual plays: `GET /sync/tracking/watched/history/{movies|episodes}`
* Ratings: `GET /sync/ratings/{movies|shows|seasons|episodes}`
* Progress: `GET /sync/tracking/playing/{movies|episodes}`
* Tracking writes: `POST /sync/tracking`, `/sync/tracking/remove`, and `/sync/tracking/remove/all`
* Individual play removal: `DELETE /sync/tracklogs/{id}`
* Rating writes: `POST /sync/ratings` and `/sync/ratings/remove`
* Progress updates and clear attempts: `POST /scrobble/pause`
Batching and API usage
Watchlist, history, and rating writes use batches of up to **500 items**. Individual play removals and progress writes use separate requests per item.
Reads currently use pages of **100 items**. Activity checks, ID resolution, and verification reads also consume API calls, so the total request count is higher than the number of write batches.
#### Diagnostics
Logging and quotas
Feature logs include `WETRAKR:watchlist`, `WETRAKR:history`, `WETRAKR:ratings`, and `WETRAKR:progress`. They report read counts, applied changes, skips, and unresolved items.
CrossWatch tracks rate-limit and daily quota headers and respects retry delays. The provider status tooltip shows remaining daily calls and the reset time when supplied by WeTrakr.
State and cache files
Snapshots are stored under `state/wetrakr/` inside the CrossWatch config directory, using hashed filenames. Caches are separated by account, connection profile, feature, and history mode.
Invalid, expired, or uncertain snapshots trigger a fresh read.
#### Notes and limitations
* The adapter is marked **experimental**.
* Collections and custom lists are not synced.
* Whole-show and whole-season history are not supported; episode history is supported.
* Unverified writes remain unresolved so the sync does not silently report success.
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://wiki.crosswatch.app/crosswatch/settings/synchronization/trackers/wetrakr.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.