The dependency I shipped on purpose

Beacon's Twitch tile depends on a free, unofficial Twitch scraper called DecAPI.me. If that API disappears tomorrow, three pieces of the tile go quiet: the live-state pill, the current game, and the sublink to recent VODs. There's no fallback; the maintainer doesn't owe me anything.

I shipped it that way knowingly.

The official replacement is the Twitch Helix API. The OAuth flow Twitch wants for this kind of read-only public data is client_credentials: register a Twitch developer application, copy your client_id and client_secret into the Beacon builder, paste them somewhere safe in case you reinstall, and now you have two new credentials to keep track of. Beacon's posture is "you should be able to set this up in an evening." Two extra credentials per Twitch tile is not an evening.

The pragmatic solution here is DecAPI, a third-party site that scrapes Twitch's public data and exposes it over a plain URL. No account, no key, just decapi.me/twitch/uptime/{username}. It works for the same reason youtube.com/@channel/videos works: the data is public and someone built a convenient interface to it. The interface might disappear, to be sure (these days, most of the open web is held up by interfaces that might disappear).

If DecAPI breaks, here's what happens to a Beacon Twitch tile: the username and avatar still render, but the live pill, game, and sublink go quiet. The page doesn't crash. Nothing the creator built depends on whether the API felt like responding today.

That's a tradeoff I made knowingly, deliberately. The cost of a digital-aggregation tool has to live somewhere: my time, the user's time, or graceful degradation if a free service goes away. I picked the third option because the failure mode is quiet and the everyday experience is one fewer thing to configure.

The fix path is documented if I ever need it: switch to Helix, snapshot at build time, keep credentials out of the deployed HTML. A couple hours of work. It's just not work I think is worth doing today.