> 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/configure-pairs/provider-settings/status-mapping.md). # Status mapping Choose which tracker statuses to sync and how they translate between providers. Status mapping translates a movie or show's watch status between supported trackers. For example, you can send **On hold** to **On hold**, map it to **Dropped**, or leave that source status out of synchronization. Rules belong to one sync pair and its selected provider instances. Configure **Shows** and **Movies** separately, and each direction separately for a two-way pair. {% hint style="info" %} **Planned** stays managed by Watchlist. Status mapping does not delete titles or create watched plays. It does not replace History sync, playback progress, or rating synchronization. Normal History sync can still add watches according to the pair settings; these rules govern the status label only. {% endhint %} ### Configure mappings 1. Open **Settings → Synchronization** and edit the pair. 2. Enable **History**. In **Providers → Status mapping**, enable status syncing. This is the same switch as **Use source watch status** in History; both History and this opt-in must be enabled. 3. Expand **Configure mappings**, choose the direction, then select **Shows** or **Movies**. 4. Check each source status you want to include, then choose its destination status. Unchecked statuses are left unchanged. 5. For a two-way pair, repeat for the reverse direction. Review both title types. 6. Choose **Conflicts**, then **Save** the pair. 7. Run [Interactive Sync](/crosswatch/main-dashboard/interactive-sync.md) and review the proposed status updates before applying them. The section appears only when both providers support custom status mapping. Available source statuses and destination choices depend on the provider and title type. ### Defaults and existing pairs Opening the controls does not activate custom rules. Existing pairs keep their existing status behavior until you edit and save a mapping. The prefilled rules include matching **On hold** and **Dropped** statuses where both sides support them; Watching and Completed are not included by default. **Reset defaults** resets the displayed direction and title type, and returns the conflict policy to **Leave unchanged**. Under **More mapping options**, **Use existing behavior** removes custom mappings; it does not turn off the History status opt-in. Save the pair after either change. If you change a provider or its instance, configure the mappings again for the new accounts. ### Destination support This table shows statuses that custom mappings can **set**. A provider may read additional statuses that it cannot write. A listed status is still subject to the restrictions below. | Provider | Shows / anime series | Movies | | ------------ | ------------------------------------- | ------------------------------------- | | CrossWatch | Watching, On hold, Dropped, Completed | Watching, On hold, Dropped, Completed | | SIMKL | Watching, On hold, Dropped | Dropped | | AniList | Watching, On hold, Dropped | Watching, On hold, Dropped | | MyAnimeList | Watching, On hold, Dropped | Watching, On hold, Dropped | | Kitsu | Watching, On hold, Dropped | Watching, On hold, Dropped | | PunchPlay | Watching, On hold, Dropped, Completed | Watching, Dropped, Completed | | WeTrakr | Watching, On hold, Dropped | Dropped | | Floppy | Watching, On hold, Dropped | Watching, On hold, Dropped | | Trakt | Dropped, restore to Watching | Read only | | MDBList | Dropped, restore to Watching | Read only | | PublicMetaDB | Dropped, restore to Watching | Read only | | Scrob | Dropped, restore to Watching | Dropped | AniList, MyAnimeList and Kitsu apply to anime titles. FlickList, TMDb and BingeBase do not support custom status mapping. ### Restrictions * **Completed:** Only CrossWatch and PunchPlay can receive this label through custom mappings, without creating watched plays. Existing Completed destinations are preserved rather than changed to another status. * **Planned and rewatches:** Planned titles remain under Watchlist control. Active rewatch states are preserved. A preference or mapping does not override these restrictions. * **Dropped shows tagging:** Use either custom status mapping or Dropped shows tagging for a pair; they cannot be saved together. * **Trakt, MDBList, PublicMetaDB and Scrob shows:** Dropped/Watching changes require existing, verified incomplete watched progress. Watching only restores a show already marked Dropped. Caught-up returning shows are not treated as Completed. PublicMetaDB needs TMDb metadata to verify unwatched aired episodes. * **Scrob:** Turn off Scrob's outbound Dropped forwarding before mapping show statuses. Movie Dropped writes require an existing unwatched title without active playback. * **MDBList:** Shows with dropped seasons are left unchanged. * **AniList and Kitsu:** Changes are skipped if they would alter an inferred history date. Kitsu also skips Watching when it would add a missing start date. * **Floppy:** Shows need a safe current season state. Watching requires an existing active season without dropped seasons; Dropped is skipped if it would also drop active seasons. Ambiguous entries and active playback are preserved. * **WeTrakr:** Movie playback pauses are not On hold. Completed shows, active playback and rewatch state are preserved. Titles must have a unique supported match. Most destinations require an existing entry. CrossWatch can create a local title-status entry when it has sufficient matching IDs; this does not create history. ### Conflicts and review **Leave unchanged** is the default conflict policy. You can prefer either provider in a two-way pair; a one-way pair can only prefer its source. For two-way synchronization, CrossWatch uses the last verified statuses to detect which side changed. Conflicting changes, or differing initial statuses without a safe choice, need the configured preference or an Interactive Sync decision. Status updates appear under **History**, showing the old and proposed status. Select only the updates you want to apply. Status conflicts can be left unchanged or resolved by choosing a provider. These rows do not use the media **Mapping** editor; edit status rules in the pair's Providers tab. CrossWatch checks the title again before writing and verifies the status afterwards. It also checks that history, progress, ratings, notes, dates and rewatch state were preserved. Unsupported or unsafe changes remain unchanged and are reported for review. An unconfirmed status write stays pending rather than being sent again automatically. Check the destination, refresh Interactive Sync, and follow the notice before selecting a retry. A different pending operation or conflicting rules in another pair can prevent further changes to that title. ### Read the result The **Status mapping** summary in Interactive Sync identifies each pair and whether it was **Preview checked**, **Checked**, **Not run**, **Check not completed**, or **Needs review**. A zero-change preview is different from a check that did not run. Review the matched, proposed, updated, unchanged, excluded and unmatched counts. **Previous writes confirmed** means an earlier pending write was verified; it does not mean another status update was sent. Use the reason shown for **Not run** or **Needs review** to decide what to correct before retrying. ### Related pages * [History](/crosswatch/settings/configure-pairs/features/history.md) * [Provider settings](/crosswatch/settings/configure-pairs/provider-settings.md) * [Interactive Sync](/crosswatch/main-dashboard/interactive-sync.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/configure-pairs/provider-settings/status-mapping.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.