Track Everything via APIs in 2026: A Free, No-Self-Hosting Browser-Extension Stack

Two earlier posts in this series ended at the same shape of answer: pick Letterboxd for movies, Serializd for TV, AniList for anime/manga, Backloggd for games, and so on. That works if you accept "I'll have four or five tabs open." It doesn't work if your goal is automatic tracking — a browser extension you write once that scrobbles every kind of media you consume, into the canonical platform for that medium, with no server to maintain and no money to spend.

This post is the API-layer answer. Strict scope, set by the previous constraints in the series:

No self-hosting. Servers cost money. Every endpoint must be a real cloud URL the extension can hit.
Genuinely free. No paid tier required for personal-scale write access. Ads on the website are fine — you'll never see them.
Must support writing. Reading public catalog metadata is easy. What's hard is "I just watched episode 3, push it to my list." That's the bar.
Cover everything. Movies, TV, anime, manga, books, audiobooks, podcasts, music, video games, visual novels, fitness, and YouTube.

A few things up front, because earlier posts in the series cut some options that should now be reconsidered under the new criteria:

Open Library wasn't picked earlier because earlier posts were about user-facing trackers, not APIs. If the goal is "what do I open on my phone to mark a book read?", Hardcover and StoryGraph are cleaner. If the goal is "what API can my browser extension hit to push reading state for free, no Goodreads-class lock-in, with a real read+write endpoint?", Open Library is the right answer, and it's what this post recommends.
Letterboxd was cut earlier because of mobile ads. It gets cut again here, harder, for a different reason: Letterboxd has no public API in 2026. Access is invite-only and not granted for browser extensions. Use Trakt for movies instead.
Music and YouTube weren't covered earlier. They are now — scrobbling music has a 20-year-old solved pattern (Last.fm / ListenBrainz), and YouTube's tracking story is uniquely awful for reasons explained below.

TL;DR — the stack

Twelve APIs, all free, all fully cloud-hosted. You wire a browser extension to each:

Medium	API	Why
Music	Last.fm + ListenBrainz (write to both)	Canonical scrobble target, 20+ years stable
Movies + TV	Trakt	Public OAuth + `POST /sync/history` scrobble endpoint
Anime + manga	AniList	GraphQL, free, no rate limits, clean `SaveMediaListEntry` mutation
Manga (alt)	MangaDex	Free token, `POST /manga/{id}/status`
Visual novels	VNDB API v2 (Kana)	Free token, `POST /ulist`, full read+write
Books	Open Library Reading Log	Free, session-based, push to Want-to-Read / Currently-Reading / Already-Read
Books (alt)	Hardcover GraphQL	If you want a modern UI on top of the same data
Podcasts	gpodder.net + Spotify Web API	Listen Notes is read-only; gpodder is the only free write API for subscriptions
Audiobooks	Open Library + LibriVox API	No public API for Audible; OL covers ISBN-tagged audiobooks
Video games	Steam Web API (read play time) + manual write to Trakt-style backend	No game platform offers a free WRITE API; this is a known gap
Fitness	Fitbit Web API	Strava made API access subscription-gated in 2025 — Fitbit is the surviving free option
YouTube videos	No official API works; build a content script that listens to playback and scrobbles to Trakt or your own store	YouTube watch-history endpoint was deprecated years ago

Read on for what each one actually lets you do, and where you'll end up writing custom code because no API covers it cleanly.

The "why one extension" architecture

Before the per-medium breakdown, the shape of the system:

Browser extension (MV3) with content scripts injected into the sites you consume on — Netflix, YouTube, Crunchyroll, Spotify Web, Open Library reader, MangaDex, etc.
Each content script detects "user finished consuming X" — usually by listening to media element events (ended, timeupdate past the 90% mark) or DOM mutations on title/episode.
A background service worker holds OAuth tokens for each platform and routes scrobbles to the right API.
OAuth flows run from the popup using chrome.identity.launchWebAuthFlow for Trakt / AniList / Simkl / Hardcover. Last.fm uses a simple API-key handshake. ListenBrainz takes a static user token.
No backend of your own. Every write goes directly to the provider's API.

That's the whole architecture. If you want a unified read-side feed later (one timeline of "everything I did this week"), you can pull history from each API back out — most of them expose GET /sync/history or MediaListCollection style read endpoints that mirror what you wrote.

Per-medium API breakdown

Music — Last.fm and ListenBrainz, write to both

Last.fm API — last.fm/api/scrobbling. API key + secret (free signup). Scrobbling is a simple HMAC-signed POST. Endpoints you care about: track.updateNowPlaying (heartbeat while a song plays) and track.scrobble (commit when finished, by convention after 50% or 4 minutes). Free tier is generous — ~5,000 calls/day. The 20-year-old industry standard.
ListenBrainz API — listenbrainz.org/api. Open-source alternative run by MetaBrainz. Static user token (no OAuth dance), POST /1/submit-listens, no documented rate limit on free tier.

Best practice: write to both. Two writes per scrobble, zero extra work, and you have a redundant copy. ListenBrainz's data is freely downloadable, which is the killer feature if you ever want your own listening history as a CSV.

The browser-extension hook: detect playback in YouTube Music, Spotify Web, SoundCloud, or Bandcamp by listening to the media element or the page's MediaSession metadata.

Movies + TV — Trakt is the only free public write API

Trakt API — trakt.docs.apiary.io. Public OAuth2. Generous free quota. The endpoints are exactly what you'd want: POST /scrobble/start, POST /scrobble/pause, POST /scrobble/stop (auto-marks watched at >80%), plus POST /sync/history for batch writes and POST /sync/watchlist. Trakt's Feb 2026 limit update raised the free-tier watchlist to 250 items, 5 lists, and 100K history rows — generous for personal use.
Simkl API — api.simkl.org. Also OAuth2, similar shape. Use it instead of Trakt if you also track anime in the same place; otherwise Trakt is cleaner for pure movie/TV.
TMDB API — free metadata + personal-list write with OAuth, but no proper scrobble endpoint. Treat it as your catalog source — you query it for poster URLs, IDs, runtime — and then write to Trakt.
Letterboxd API — does not exist publicly in 2026. Access is invite-only and not granted for browser extensions. This is why Letterboxd is cut from this stack despite being the best movie-only tracker UI. If a public API ever ships, swap it in for the movie scrobble; until then, Trakt.

Browser-extension hook: detect playback on Netflix, Disney+, Prime, Apple TV, Hulu, Max — content scripts that read the title from the player UI and match against TMDB IDs, then push to Trakt.

Anime + manga — AniList GraphQL is the cleanest API on this list

AniList GraphQL API — docs.anilist.co. OAuth2, no rate limits on the free tier, single endpoint (/graphql), and the mutation you want is exactly one query: SaveMediaListEntry with mediaId, progress, and status. There isn't a cleaner public API for media tracking anywhere on this list.
MyAnimeList API v2 — works, OAuth2, ~60 req/min. Use as a fallback or to mirror writes if you have a long MAL history.
Jikan — read-only proxy of MAL, no auth. Use only for metadata lookups.
Kitsu JSON:API — free, OAuth2, write supported. Good third option.
MangaDex API — POST /manga/{id}/status for reading status; pair with AniList for the canonical list and MangaDex for "this is where I actually read it."
Bangumi (bgm.tv) API — OAuth2, free, covers anime + manga + games
- books + music. Niche but the API is real.

Browser-extension hook: content scripts on Crunchyroll, HiDive, AnimeLab for anime episodes; MangaDex, Bato.to, Mangakakalot for manga chapters. The MAL-Sync browser extension is open-source and a useful reference implementation.

Books — this is where Open Library shines

This is the question the previous posts dodged. Under the API lens, the answer changes:

Open Library API — openlibrary.org/dev/docs/api. Run by the Internet Archive. Free. Comprehensive book metadata via search.json, works/, ISBN lookups, covers — and crucially the Reading Log that lets an authenticated user push books to Want to Read, Currently Reading, or Already Read shelves. Authentication is session-based, which is a slightly weird shape for a browser extension but solvable (cookie scope on openlibrary.org). This is the canonical free-and-open books API and it's what your extension should write to.
Google Books API — free with OAuth2 and a 1,000 req/day quota; can manage user bookshelves. Useful as a secondary write target, especially if you also use Google's reader on Android.
Hardcover GraphQL — api.hardcover.app. Free JWT, GraphQL mutations to push reading status, decent rate limit. The right pick if you want a polished mobile UI on top of the same writes.
StoryGraph API — still not released as of 2026 (long-standing feature request). Use Open Library or Hardcover instead.
Goodreads API — dead. Closed to new applications in 2021, legacy keys deprecated 2023. Don't build on it.

Why Open Library specifically? Three reasons: (1) it's a non-profit (Internet Archive) and won't pull a Goodreads/Pocket shutdown; (2) the data is freely downloadable in bulk, so your reading history is portable forever; (3) the catalog is the most complete free book database on the internet, and the API exposes it without an API key for reads.

Browser-extension hook: content scripts on Amazon book pages, Google Books, Kobo, and your library's OPAC — extract ISBN, push to Open Library Reading Log.

Audiobooks — half-solved

Audible has no public API. The free options are:

Open Library — covers ISBN-tagged audiobook editions, which overlap with regular book entries. Track them as books.
LibriVox API — public-domain audiobooks, free, read-only.

If you listen on Audible specifically, your only path is a content script that detects "finished a chapter" and pushes it to Open Library or Hardcover as if it were a regular book.

Podcasts — the worst-served medium for write APIs

This was the surprise of the research. Almost every podcast API is read- only:

Listen Notes — free tier, read-only. No personal listen endpoint.
Podcast Index API — free, open, indexing-focused. No personal scrobble endpoint.
iTunes Search API — search-only.
gpodder.net — the only free public API that accepts WRITE for podcast state (subscription sync, episode-played status). Account- based, reasonable rate limits, OPML/JSON. Use this.
Spotify Web API podcasts — OAuth2, can save shows and episodes, but no listen-history scrobble.

The honest answer: you scrobble podcasts to Last.fm or ListenBrainz as if they were music tracks. Both accept arbitrary "track" metadata; many people already use ListenBrainz this way for podcast listens because there's no first-class podcast scrobble target in the open API world.

Browser-extension hook: content scripts on Spotify Web (/show/, /episode/ URLs), Pocket Casts web, Overcast web — push the listen to ListenBrainz tagged as a podcast and to gpodder for subscription state.

Video games — no free public WRITE API exists

Spent the most time confirming this. As of 2026:

IGDB (Twitch) — free, metadata-only.
RAWG — free, metadata-only.
GiantBomb — free, metadata-only.
Steam Web API — free, READS your owned games and play time (which Steam logs automatically), but no endpoint to write a gameplay event. Steam logs play time itself via the desktop client.
Backloggd — no public API.
HowLongToBeat — no official API.

The workaround pattern: your extension pulls Steam's GetRecentlyPlayedGames for read-side automatic tracking, and for non-Steam games (consoles, GOG, Epic) you fall back to manual entry into a Trakt list or a custom collection.

This is the cleanest example of a gap in the free API map. If games are critical to your stack, you accept Steam's auto-logging for PC and one of three things for everything else: Backloggd account (manual web UI), a Trakt list with your own ID convention, or wait for a public IGDB write API that may never come.

Visual novels — VNDB is perfect

VNDB API v2 (Kana) — api.vndb.org/kana. Free token, REST with POST queries, POST /ulist for full read+write of personal lists with notes, votes, and status. Open-source TS wrapper exists.

This is the simplest medium on the list — one API, free, complete.

Fitness — Strava just got worse, Fitbit is the survivor

Strava API — was the canonical free fitness API, but in 2025 Strava moved API access to require a paid Strava subscription on the Standard tier for new developers. Fails the strict "genuinely free" rule.
Fitbit Web API — dev.fitbit.com/build/reference/web-api. Free, OAuth2, 150 req/hour. Full read+write — POST /activities to log a workout. Now part of Google.
Polar AccessLink — free for personal use, OAuth2.
Health Connect (Android) and Apple HealthKit (iOS) are device-side, no public cloud API. Use a small companion app to relay to Fitbit if you want them in the cloud.
Garmin Connect — public API exists but the partner program is gated; not freely usable.

Browser-extension hook is awkward here because fitness happens off the browser. The pragmatic answer: a small Android Health Connect app or Fitbit's own automatic upload keeps the data flowing, and your extension just reads Fitbit on demand for the unified timeline.

YouTube and general videos — the broken one

This is the annoying one and the reason your extension exists:

YouTube Data API v3 — developers.google.com/youtube/v3. Free 10,000 units/day quota. Reads video metadata, channels, playlists, liked videos, and subscriptions. Watch history is not exposed; the activities.list watch-history endpoint was deprecated and removed years ago. There is no API path to programmatically access "what videos has this user watched."
Invidious / Piped — open-source YouTube proxies. Read-only, no user state.
Vimeo API — free, OAuth2, exists but irrelevant for general video consumption.

The only way to track YouTube watch history is a content script that listens to YouTube playback. Concretely: inject a script into youtube.com/watch*, attach to the <video> element's timeupdate event, and when playback crosses ~80% emit a scrobble. Push it to:

Trakt — yes, you can scrobble YouTube videos to Trakt by treating each as a movie/episode-shaped item; many open-source extensions do this.
A Last.fm/ListenBrainz "track" — works for YouTube Music specifically.
A side store — if you want pure YouTube history outside the movie-tracker frame, Raindrop.io has a free OAuth2 write API and is the most pragmatic "throw a bookmark with metadata at it" target left standing after Pocket and Omnivore both shut down.

This is the single biggest piece of custom code in the stack, and it's unavoidable.

Read-it-later articles — Pocket is dead

Worth flagging because it changes recent advice:

Pocket — shut down July 8, 2025; API disabled November 12, 2025. Mozilla EOL'd the service.
Omnivore — shut down 2024.
Readwise Reader — paid only.
Raindrop.io — free tier, OAuth2, full read+write API. The surviving cloud option.

If you also want article-style tracking (long reads, things you saved from Hacker News), Raindrop is the right target.

Coverage matrix and the honest gaps

Medium	Free public WRITE API?	Best target	Gap / workaround
Music	✅	Last.fm + ListenBrainz	None
Movies	✅	Trakt	Letterboxd has no public API
TV	✅	Trakt	—
Anime	✅	AniList	—
Manga	✅	AniList + MangaDex	—
Visual novels	✅	VNDB v2	—
Books	✅	Open Library Reading Log	Goodreads dead, StoryGraph API still unreleased
Audiobooks	⚠️	Open Library (book entries)	No Audible API
Podcasts	⚠️	gpodder.net + ListenBrainz (as tracks)	No first-class scrobble target
Video games	❌	Steam read-only auto-log	No free WRITE API anywhere
Fitness	⚠️	Fitbit	Strava went paid in 2025
YouTube	❌	Custom content script → Trakt or Raindrop	API watch-history endpoint was killed

Three categories don't have a clean answer: video games (no write API exists), YouTube watch history (no API access at all — content script is the only path), and fitness (Strava is no longer free, Fitbit works but you need the device).

The good news: those three are the only gaps. Everything else has a real, free, cloud-hosted write endpoint in 2026.

Should you build a website, or just an extension?

The original question. Given the constraints — no self-hosting, no recurring costs, all data lives on the providers — don't build a website. The architecture you actually want is:

A browser extension (Manifest V3, JS or TS). The whole product.
No backend of your own. Every write hits a third-party API directly. Your "database" is the union of what each platform stores for you.
A read-side dashboard inside the extension popup that fans out GET requests to each platform on demand and stitches the results into one timeline. This is fine for personal scale (you, alone, refreshing once a day).
Backups via cron — a GitHub Actions workflow on a free tier account that pulls each API's full history weekly and commits the JSON to a private repo. Free disaster recovery.

What this gives you: the tracking surface of a $50-a-year all-in-one SaaS, built on top of public APIs that have been stable for a decade, with zero monthly cost and your data portable across every provider.

What it doesn't give you: a polished mobile app, push notifications, a shareable public profile, or recommendations. You're trading those for zero recurring cost and total data ownership.

Why not the open-source self-hosted apps

To address this directly since the question keeps coming up: Ryot and Yamtrack are excellent, they cover almost everything on this list (movies, TV, anime, manga, books, audiobooks, podcasts, music, games, visual novels, fitness — the full set), but they require Docker on a server you pay for. A $5/mo VPS is the cheapest path, plus domain, plus backups. That's$ 60–$100/yr.

If your hard constraint is "no recurring cost," self-hosted is out by definition. The browser-extension architecture in this post is the strict-zero-cost alternative.

Implementation tips

A few things that aren't obvious from the docs:

OAuth in MV3 extensions — use chrome.identity.launchWebAuthFlow with the redirect set to your extension's chromiumapp.org URL. Trakt, AniList, Hardcover, Simkl, and Spotify all accept this.
Last.fm's auth handshake is older and uses a desktop-style flow with auth.getToken → user opens browser → auth.getSession. Slightly awkward in an extension; do it once and persist the session key.
Token storage — chrome.storage.local is fine for personal use; encrypt at rest if you're paranoid.
Scrobble timing — stick to the Last.fm convention: emit "now playing" on start, commit the scrobble at >50% or after 4 minutes, whichever comes first. Apply the same rule across video platforms (translates to "watched at >80% of runtime").
Catalog ID matching is the actual hard part — the player gives you a title, you need a TMDB or AniList ID. Build a small fuzzy-match layer that hits each platform's search endpoint and caches results; fall back to manual confirmation in the popup when the match confidence is low.
Rate limits — stagger writes when batch-importing history. AniList and Trakt are generous, but a thousand calls in 30 seconds will get you throttled.

Closing

The honest answer to the question — "track everything, free, no self-hosting, only APIs" — in 2026:

Twelve APIs cover ten of the twelve media types cleanly.
Two have real gaps: video games (no free public write API anywhere) and YouTube watch history (no API access — only a browser content script).
Open Library is the right book API even though it's not the prettiest tracker UI.
Letterboxd is out, not because of ads but because it has no public API.
Last.fm + ListenBrainz is the music answer, written to in parallel.
AniList GraphQL is the cleanest API in the entire stack — make it the model your other integrations imitate.

Build a Manifest V3 browser extension. Wire it to those twelve APIs. Don't run any servers. The whole tracker exists in your browser, the data lives across twelve providers that have collectively been stable for over a decade, and your monthly cost stays at exactly zero rupees.