🔔 Upcoming Change: Seconds and Milliseconds Will Be Zeroed Out in watched_at Timestamps

[kevincador]

Hi developers,

We want to let you know about an upcoming change to the Trakt API that may affect integrations working with watch history.

📅 Timeline

This change will progressively roll out over the next few weeks to complete March 1st.

🛠 What’s changing?

Trakt is standardizing all watched_at timestamps to always have seconds and milliseconds set to 00.000Z.

This applies to:

• timestamps already stored by Trakt, and
• timestamps submitted to Trakt going forward.

Some before/after example:

• Existing history: 2014-03-31T09:28:53.890Z will become 2014-03-31T09:28:00.000Z
• Newly submitted: 2026-03-01T09:28:53.423Z will become 2026-03-01T09:28:00.000Z

To be ultra clear:

• The timestamp format does not change
• The seconds and milliseconds portion will always be 0

This applies to any endpoint that reads or writes watched_at.

🎯 Why are we making this change?

We’ve seen recurring issues where multiple third-party apps, scrobblers or devices report the same watch event with slightly different timestamps (often differing only by seconds or milliseconds).
These small differences prevent reliable deduplication and result in many duplicate watch history entries.

Standardizing watched_at to minute-level precision:

• naturally deduplicates watch events created by competing or overlapping integrations,
• reduces ambiguity when multiple sources report the same playback,
• aligns with how users actually think about watch events (minute-level accuracy is sufficient).

Seconds and milliseconds don’t meaningfully represent a watch event, but they do introduce edge cases when comparing, matching, or syncing history across systems. This change removes that class of problems entirely.

🔧 What you need to do

• If you already ignore seconds and milliseconds when syncing play events, you’re all set.
• If your sync logic relies on seconds or millisecond precision for deduplication or matching, we highly recommend adjusting that logic as soon as possible.
• There is no need to change how you parse timestamps. The format stays the same.

🔄 Backwards compatibility

• We will still accept timestamps with seconds and milliseconds.
• All existing data remains compatible and readable.

📣 Feedback

If you think this change may impact your integration or workflows in ways we didn’t cover, please reach out.

Thanks for building with Trakt 🚀

[UweTrottmann]

A few years back (~2022) Trakt has changed to allow adding duplicate history entries. See also the note in the Add to History API docs about it.

Does this also mean Trakt will again not add a duplicate history entry if the watched_at time is identical? So API clients won't have to check if an entry for that time already exists (e.g. in case of a network or server error an add request is retried)?

[UweTrottmann]

Based on a quick test it appears this is the case.

[kevincador]

The API doc will be updated to reflect the change.

Yes, the whole point of this change is to be able to naturally deduplicate item + watched_at.

If you currently have logic in your app to handle duplications, you can remove it now.