Synchronization
Adapter reference for how CW reads/writes provider data during syncing.
Last updated
Was this helpful?
Adapter reference for how CW reads/writes provider data during syncing.
Synchronization adapters are the “connectors” the orchestrator uses for syncing. Each adapter knows how to read a provider and how to write changes back.
Related: CW Orchestrator.
If a provider behaves unexpectedly, start with its adapter page.
Start with one pair and one feature. Expand only after the first run is clean.
Use Authentication.
Adapters implement the same core flow:
Index: fetch a present-state snapshot (what exists now).
Normalize: turn provider rows into common items + stable IDs.
Apply: add/remove/update on the target side.
Stabilize: use local state to avoid repeats and flapping.
Watchlist: set-like. Adds and removes are straightforward.
History: event-like. watched_at matters. Duplicates are common.
Ratings: numeric. Scale differences matter. Deletes can be destructive.
Playlists: ordered. Often provider-specific. Not widely supported yet.
Snapshot caching to reduce API load.
Chunking + small pauses to avoid rate limits.
Shadow/unresolved files to prevent endless retries.
Activity/watermark logic for delta providers (example: SIMKL).
Adds keep reappearing: provider didn’t “stick” the write. Check adapter state files.
Recent changes not syncing: reduce caching, or force a fresh read if supported.
429 / 5xx errors: reduce chunk size, add delay, run less often.
Mismatches: add Metadata / ID Mapping and prefer stable IDs.
Configure Pairs — step-by-step pair setup.
Best practices — safe defaults.
Last updated
Was this helpful?
Was this helpful?