Trakt 删了我的 API app

7 月 31 日晚上,我发现「在看什么」那页停在 7 月 25 日。

没有错误讯息。伺服器没挂、页面正常渲染、动画那半边还在更新——只有电影和影集那半边,停住了。

去 Trakt 官网想手动重登,结果更怪:明明登入成功,每次跳转都被踢回首页。

而 UTS 那边看起来完全正常——它照样抓到我看了什么,照样显示配对结果。

一个「没有任何一处报错,但资料就是不再流动」的故障。后来才知道,那天全世界有一批人跟我卡在同一个地方。

两个字串#

翻到后端日志深处,只有两个东西:

client not found
session not found

client not found 这句话的意思很明确——Trakt 那边查不到我的 OAuth app 了。不是密钥过期、不是 token 失效,是那个 app 本身不存在。

去 Trakt 的 API 设定页确认:空的。我几个月前建的那个 app,不见了。

它是被谁删的#

Trakt 的网页前端是开源的,所以这件事不需要猜。

trakt/trakt-web 的 PR #3057,标题 feat(settings): make api application creation vip-only,作者是 Trakt 自己的开发者 vladjerca,2026 年 7 月 30 日建立,同一天合并。

改动内容包括这几条新的介面字串:

"Creating new apps requires Trakt VIP"
"VIP members can register unlimited OAuth applications."

以及把建立按钮包进 <RenderFor audience="vip">。

到这里为止都还合理——一家公司决定某个功能只给付费会员,那是它的权利。

但这个 PR 只做了「挡住建立」。 它的说明里写得清清楚楚:免费使用者会在应用程式清单上方看到一张升级提示卡,而那份清单本身是 "(still readable)"——仍然可读。

从头到尾,没有任何一个字提到会删掉既有的 app。

而我的 app 不见了。GitHub 上的 issue #3061 标题就叫 "Can't see API apps",开票的人说他的 app 是「v3 出现之前」就建的,现在整份清单是空的,而他的整合开始收到 403。底下四则留言,全是同一件事:

my API app was deleted without warning. Not a VIP here either, but i feed them data and now get nothing in return. Is this intentional?

The lack of notice just plain sucks. Whoever took that decision needs to hire a comms team...

「没公告」这件事,可以用他们自己的纪录证明#

这不是我的主观感受,是可以查的。

trakt/trakt-api 这个 repo 有一个 Announcements 分类,而且他们平常真的在用:

连「时间戳的秒数之后会归零」这种等级的改动,都会事先发一则预告。

而截至本文写作,那个分类最新一则公告仍停在 6 月 11 日的文件更新。删掉一票人 API app 这件事,一则都没有。

所以能证明的是:他们有这个机制、平常会用、这次没用。 不能证明的是动机——我看不到任何内部纪录。但目前所有看得到的行为,都指向同一个方向。

四天后,官方回应了#

8 月 3 日,Trakt 的人终于出现。回应的方式比内容更值得记录——同一分钟内发生了三件事:

This is just a temporary measure to prevent abuse. Our intention is to keep the API accessible for developers. We'll have more to announce soon.

下一则留言来自另一位开发者,他的 app 上架在 App Store:

Why don't you communicate about it BEFORE deleting API apps then? Give us some notice and some delay before doing such moves, you shouldn't cut access like that, some of us depend on those for production apps. ... You've lost my trust as well.

而那句 "temporary",到今天为止:PR #3057 没有被回退,官方公告仍然没有,期间倒是又上线了一个新的 VIP 功能。

同一时间,这件事在三个地方被讨论,而它们现在的状态刚好跟「谁拥有那个平台」一致:

论坛那串我特地确认过不是网址写错:同一台伺服器的搜寻 API 回应正常,只有那个主题不存在了。至于是谁删的,我没有证据,不写。

Reddit 那串倒是有个容易误读的地方——原始贴文显示 [deleted],但那是发文者自己删的,页面上写得很清楚,留言全都还在。我一开始差点把它算成「又一个被消失的讨论」,查清楚之后发现不是。

那 60 则留言里,最高票的一句是:

Trakt is speedrunning the dumbest path to monetization.

而另一则留言提醒了我一件事——对那里的人来说,这不是单一事件:

they redesigned their UI which everyone hates, got rid of the option to use the old version of the site, increased pricing for VIP, and now cut off their API for free users. I'm sure there's more that I'm forgetting, but it's all anti-user.

我只用了 Trakt 两个月,没有立场评论前面那几件。但这解释了为什么那串的情绪比「一个 API 坏掉」该有的强度高得多。

先搞清楚我到底失去了什么#

在找替代品之前,我先查了一件更基本的事:我的资料到底是怎么进来的?

结果跟我以为的不一样:

netflix      788 笔   全部在 2026-05-28 同一秒写入   ← 一次性历史汇入
trakt        155 笔   电影更新到 7/25、影集停在 5/29
letterboxd     1 笔   2026-05-28 一次性

那 788 笔 Netflix 是我自己下载 CSV 汇进去的,一次性,之后再也没动过。Trakt 只有 155 笔,看起来微不足道——

但它是唯一还在流动的来源。它占比小只是因为它才跑了两个月。

也就是说:Trakt 一断,我的电影与影集纪录就完全没有自动来源了。(动画那条走的是我自己写的动画疯同步,不受影响。)

顺带查到一个一直没发现的问题:那 151 笔影集纪录,watched_date 全部是 NULL。Trakt 从来没给过我逐集的观看时间。这件事等一下会变成选择的关键。

三个看起来可行的方案,查完全部出局#

我试着找能接上原本架构的东西。判准只有一个:它必须能让我的后端把资料拉回来。

Yamtrack   rest_framework / api/urls  → 0 个结果
Floppy     rest_framework / APIView   → 0 个结果

判准其实早就写在架构里#

绕了一圈之后我意识到:我不需要重新设计这个功能。需求就写在我已经盖好的东西里。

要换的只是中间那一颗。所以判准变得很明确:

为什么是 Simkl#

Simkl 第一个通过的测试很单纯:它的公开端点不用任何凭证就回资料。

curl https://api.simkl.com/movies/trending   # 直接就有回应

Trakt 连 trending 都要 api-key。这是一个关于「这家公司怎么看待 API」的讯号。

然后我发现架构几乎是一比一对应:

那个 PIN 流程(device flow)对我特别有价值:token 是靠轮询 /oauth/pin/{USER_CODE} 拿的,整个过程没有任何 callback 打回我的伺服器。我当初为了 Trakt 那套 redirect 开的对外端点,可以省掉。

但我要把话说清楚——

写程式之前,先把不确定的都打掉#

被烧过一次之后,我不想再赌。所以在动任何一行后端程式码之前,先做最小验证。

{ "access_token": "…", "token_type": "bearer", "scope": "public" }

有一条规则会直接决定实作方式#

Simkl 的文件里有一段警告,粗体是他们自己标的:

Never run unconditional background polling timers without active user interaction. Ensure you always use date_from to avoid overloading the API server. If you don't follow these rules, your client_id will be suspended.

我原本 Trakt 那套是每 6 小时无条件全量拉。照搬过去,client_id 会被停权——那等于自己动手重演一次 Trakt。

正确做法是他们文件写的三段式:

每 N 小时：
  1. GET /sync/activities        ← 很轻，只回一堆时间戳
  2. 跟本地存的游标比对，一样就结束  ← 绝大多数的轮询停在这里
  3. 有变才 GET /sync/all-items/?date_from=<上次的时间戳>

这比 Trakt 那套分页硬拉干净太多,而且大部分时候根本不会产生第二个请求。

实际迁移#

后端的新模组大约 300 行,取代原本 450 行的 Trakt 逻辑。差异不只是行数:

游标存哪这件事,我特地没有沿用档案——Trakt 那个 token 档就是痛点。但既有的计数表栏位是整数,存不了 ISO 时间戳,所以另外开了一张很小的 sync_state 表。

三个坑#

- SIMKL_CLIENT_ID=${SIMKL_CLIENT_ID:-}

/sync/movies            → 0 笔
/sync/all-items/movies  → 1 笔

顺手做了一个 fork#

Simkl 的官方扩充只做 Netflix 和 Crunchyroll,而 UTS 支援 29 个平台——Disney+、HBO Max 那些都在里面。

我不想为了换 hub 而放弃那些平台,所以去量了一下把 UTS 改成送 Simkl 要多少工。答案比预期好:

要改写的 Trakt 相关    约 1,396 行（8 支档案）
29 支平台撷取器        完全不用动
  disneyplus  提到 Trakt 0 次
  hbo-max     提到 Trakt 0 次

撷取器跟 Trakt 是干净解耦的。 那些平台各自的网页结构有多难搞,上游已经替我踩过了,而那部分跟后端是谁完全无关。

所以这个 fork 的本质是「换掉后端,继承 29 支撷取器」,不是重写。上游是 MIT 授权,我用 GitHub 的 fork 而不是复制程式码——保留 commit 历史与原作者的贡献纪录,授权关系也最清楚。连结放在文末。

过程里最值得记的一件事:改名让型别检查全绿,建置却炸了。

改名脚本把程式码里引用的图示档名改了,实际的档案没改。型别检查看不到资产路径,是打包阶段才解析失败的。所以我在 CI 里把 build 补了上去——原本只跑型别检查跟 lint,那类问题两个都抓不到。

另外有一个会静默出错的东西,我觉得比建置炸掉危险得多:上游有个功能会去社群资料库抓「配对修正」的建议,而那里面全是 Trakt 的 ID。在 Simkl 上套用会配到毫不相干的条目,而且不会有任何错误讯息。整个停用了。

现在的状态#

8 月 4 日,我在 Netflix 看完一部电影。没有做任何事。

排程到点的时候,后端先问了一次 activities,发现时间戳变了,才去拉那一段增量,写进资料库,补了 TMDb 的图。等我想到要去看的时候,它已经在页面上了。

整条管线是通的:

但有一件事我没有做完,不想写得像全部搞定了。

「现在正在看」那个即时状态,目前只有动画那条还活着。Trakt 的即时状态随着那 377 行程式码一起被移除了,而 Simkl 这条我查过之后决定先不接——因为扩充功能只在播放、暂停、停止三个时机才打 API,连续播放一整部片的期间,Simkl 那边收不到任何更新。拿它的「暂停中」资料当「正在看」,显示出来的会是两天前停在 1% 的东西。

正确的做法是让扩充直接把心跳送到我自己的伺服器,绕过 Simkl——动画那条就是这样做的。但那需要在一个公开发布的扩充里带着我伺服器的凭证,而发布出去的安装档任何人都能下载。这是个还没解决的设计问题,不是照抄就能做完的事。

这一页本来是怎么盖起来的,写在这篇: