RSS Watch is the Tools service for collecting, reading, and following content from RSS sources and websites monitored by the service. The public documentation describes how the collected material can be read and used. The collection and worker pipeline itself is internal operations and is not a public API for creating or writing your own entries.
The main reader is available at /feed.
It can be used to:
/feed/c/{categorySlug} and /feed/cards/{categorySlug}/feed/{id}/cards/feed/key/{publicHash}/cards for a hidden feed when you have been given its public hash linkEach expanded site card in the main feed browser has a Cards action beside the normal feed and RSS actions. The site magazine view is scoped to that single feed: its article grid contains only entries from the selected site, and the analysis cards use that site's own daily, weekly, monthly, and yearly AI analyses when available. Pagination, history mode, history limits, and article diffs remain available in the magazine presentation. Switching between the selected analysis and all analysis variants keeps the current magazine controls in place.
RSS Watch stores history so it can show how captured content changed over time. An RSS Watch entry therefore does not necessarily represent a standalone article copy; it can represent a captured version of content from an external source.
RSS Watch can maintain daily, weekly, monthly and yearly AI reports for categories and individual feeds. Reports follow the period buckets they actually cover, so regenerating an older report later does not make that old period become the current report or let it use a newer period as its comparison baseline.
Administrators manage report lifecycle at /admin/rss-reports. Every cadence has an independent retention policy. keep_all keeps historical periods while the current bucket can continue to update. overwrite removes older matching reports only after the replacement report is actually ready, so a failed generation cannot delete the last working report.
Optional previous-period comparison uses the exact preceding bucket for the selected cadence and stored report data, not model memory. Stored comparison context is reused only when it matches that expected preceding bucket. Category- and site-specific report instructions apply to manual and scheduled generation, and the AI structure advisor can suggest analysis instructions, presentation guidance, a reusable title and tone from a bounded feed snapshot.
Magazine pages deliberately show exactly one selected AI report even when history is retained. The preferred magazine cadence is independent from retention, and fallback selection follows the newest period covered rather than whichever historical report happened to be generated most recently.
Users with RSS editor permission manage configured sources at /rss. The editor groups sources into category cards and keeps both category contents and individual feed editors collapsed until they are opened. This keeps large RSS installations usable without displaying every setting at once.
Ordinary editing is AJAX-first. Changes to feed fields are saved in place with visible save state, and adding or deleting a source updates the card list without forcing a page reload. Pagination remains available for larger source lists. Advanced XPath/JSON rules stay behind an expandable section, while Authors mappings, hidden-feed settings, public hashes, XPath Lab, and orphan cleanup remain available where applicable.
The /rss toolbar also links directly to AI & analytics. That destination is the existing RSS analytics configuration surface for category/site analyses, analyst focus, personas, tones, languages and scheduled generation. Cached category-analysis panels use the same clearly named configuration link instead of the historical generic Feed Admin wording. Home/public-news presentation remains a separate control even though some of the older routes still share the feed-admin prefix.
Categories can be renamed directly from a category card. Each category also has a stable editable slug in the same AJAX editor. Renaming the display name keeps the current slug by default, so existing /api/rss/feed/{categorySlug}, /feed/c/{categorySlug}, and /feed/cards/{categorySlug} links do not change just because the category label changes. If an administrator explicitly changes the slug, the previous slug is stored as a historical alias and remains accepted. Previous category names are also retained as aliases, including rename history recovered from the structured RSS audit log when identity storage is first introduced.
A category rename is a global RSS operation rather than a label-only display change: Tools updates the exact category term on affected feeds and keeps the related category analytics, category settings, content-AI rules, allowed question categories, stable identity, aliases, and audit history linked to the current category. Per-feed category fields can also contain multiple comma-separated categories and save through AJAX.
Users with RSS editor access can use the Auto action in the Add URL form with either a normal URL/domain or a plain search term. A URL keeps the ordinary direct feed detection flow. Plain text such as a person, publication, organization or subject starts an OpenAI web search first.
The interactive source-resolution call uses the authenticated JSON route POST /api/rss/resolve-source. It is intended for the editor AJAX flow, requires the same RSS permission as the editor, and must return JSON instead of following a web redirect.
The search must establish a clear connection between the complete search term and the selected public source. Named people and organizations prefer their own official site when one can be established. Generic subjects use a public source whose primary content clearly concerns that subject. A weak or uncertain match is rejected instead of being turned into a guessed URL.
The editor shows the process in stages: source search, source/feed inspection and completed detection. OpenAI also looks for an explicit RSS or Atom link while resolving the source. Any suggested feed is verified before it is used. The normal WordPress, RSS, Atom and XPath detection then continues against the resolved source page, and the resolved page remains the origin URL for the new entry.
RSS Watch normalizes HTML that uses the legacy XPath extractor before DOM parsing so ordinary UTF-8, Windows-1252 and similar legacy input can be presented consistently. Confirmed RSS/Atom XML from scraper workers is now normalized before the backend stores the inbound payload, so high-confidence encoding damage can be corrected before article fields are extracted. Public feed presentation also normalizes text on the fly when older stored rows contain non-UTF-8 bytes.
Already-valid UTF-8 can still contain mojibake if the bytes were interpreted with the wrong character set earlier. RSS Watch detects common patterns and can apply a small bounded sequence of reversible Windows-1252/UTF-8 reinterpretations when repeated encoding damage requires more than one pass. Every accepted pass must round-trip exactly, lower the mojibake score and produce a clearly better final result. Uncertain or mixed-Unicode cases are left unchanged.
Users with RSS editor permission can inspect text or HTML at /rss/encoding. The tool remains read-only. When an already stored article has high-confidence repairable damage, a signed-in administrator can instead use the explicit Repair encoding action on the article/site card. That permanent action rewrites only repairable text fields, refreshes content hashes when visible article text changes, and leaves links, ids and permalink identity untouched.
The production host is https://tools.tornevall.net.
Public read requests include:
GET /api/rss - list publicly available feeds and categoriesGET /api/rss/feed/{selector} - retrieve a feed by numeric id, stable category slug or historical category alias, public hash, or a supported analytics selectorExample:
https://tools.tornevall.net/api/rss/feed/1
Analytics feeds can also be read through daily, weekly, monthly, yearly, and bulk selectors when the corresponding analyses exist.
Worker ingestion, scheduling, internal update, and maintenance endpoints are intentionally not documented in the public guide. They are part of the Tools operational contract and must not be used to create custom RSS Watch entries.
/feed includes the "Ask about all open feeds" feature for questions against open RSS data. Question history is available at /feed/user-questions.
Guest use is protected by Cloudflare Turnstile and quotas. Signed-in users have their own quotas, while administrators have expanded access for operations and review.
Signed-in users can use RSS Watch subscriptions where available to receive updates from selected feeds or categories. The delivery channels shown depend on the current Tools configuration and services connected by the user.
Website operators may see RSS Watch traffic when the service fetches a configured source. Current workers identify themselves as RSSWatchBot and link back to this documentation in their User-Agent. That information is public so site operators can understand why Tools is fetching a page and who is responsible for the traffic.
Internal worker ids, log paths, payload formats, and write requests are not part of the public integration surface.
Questions about a feed, incorrect material, corrections, or removal requests can be sent through the Tools contact page or to support@tornevall.net.
RSS Watch predates the current Tools implementation by many years. The project started around 2010 as an RSS reader with an unusual focus on detecting changes to already published text, disappearing posts, and edited comments. It has since been shut down, revived, and rebuilt across several generations.
See RSS Watch - project history for the preserved development timeline and its source material.