Machine-readable changelogs: feeds, APIs, and llms.txt for scripts and AI agents

Picture the readers of your next release note. A customer, sure. A teammate. But increasingly also: a dependency-update bot embedding your notes in someone's pull request, a monitoring script asking "did the vendor ship the fix yet?", a dashboard aggregating what all your suppliers changed this week — and, newly, an AI agent deciding on a user's behalf whether upgrading to your latest version is safe. A changelog that exists only as styled HTML (or worse, only inside a JavaScript widget) is invisible to every one of them. This guide is about serving both audiences from one source: prose for people, structure for software.

Who the machine readers actually are

• Dependency-update bots. Dependabot, Renovate, and friends open the bump PR and embed your release notes in it. Your entry gets read inside someone else's code review, during a 30-second merge decision — the open source changelog guide covers writing for that reader. But before writing style matters, the bot has to be able to find your notes at all: a feed or Releases API, not a marketing page.
• CI and internal scripts. "Page the on-call if our payment provider posts anything tagged breaking." "Block the deploy if the SDK we pin shipped a security fix we haven't taken." These are five-line scripts when your changelog has a queryable surface, and unbuildable when it doesn't.
• Aggregators and dashboards. Teams increasingly keep a "what did our vendors change" feed. RSS made this a solved problem twenty-five years ago — for the sites that expose it.
• AI agents. Agents now do upgrade triage ("is it safe to bump this dependency?"), answer support questions ("did X fix the export bug?"), and in some cases operate products end-to-end. An agent can scrape your HTML, but scraping is slow, brittle, and often wrong; structure is cheap and exact.

The format ladder: what to expose

You don't have to build all of these. Each rung serves strictly more consumers:

• RSS (or Atom). The universal minimum. Every pipeline tool, chat bridge, and aggregator built since 2000 speaks it; a feed reader is still how many developers follow vendor changelogs. If your changelog has no feed, you have opted out of decades of existing plumbing. (It also powers low-effort mirrors — see posting to Discord and Slack.)
• JSON Feed. Same idea, trivially parseable in any language without an XML library: items[].title, date_published, content_html, url. For a script author this is the friendliest rung — curl | jq and you're done.
• A structured list API. The difference from a feed: fields instead of prose. Tag/category as a field, date as ISO 8601, stable per-entry URL and ID, body as both markdown and HTML. This is what upgrade-triage tooling actually wants: ?tag=breaking beats parsing paragraphs every time.
• CHANGELOG.md in a conventional format. Semi-structured: the Keep a Changelog format is regular enough that parsers exist, it travels inside tarballs, and it's greppable offline. Fragile as a sole machine surface (one creative heading breaks parsers), excellent as a portable export.

The structure machines need

Whatever surfaces you expose, five properties decide whether they're usable:

• Stable IDs and permalinks. Every entry needs a URL and a GUID that never change. Feed readers and bots dedupe on the ID: change it, and every subscriber gets re-notified about old news; drop the permalink, and nothing can link to or cache your entry.
• ISO 8601 dates, with timezone. 2026-07-27T14:00:00Z sorts, compares, and parses in one line everywhere. "July 27th" costs every single consumer a date parser and a timezone guess — and "is this newer than the version I run?" is the machine reader's most common question.
• Categories as data, not prose. A tag field with a small fixed vocabulary (new / improved / fix / breaking…) lets a script filter without natural-language processing. "This release addresses an issue where…" buried in a sentence does not.
• Breaking changes flagged structurally. The single highest-value bit of machine-readable data you can publish. A tag, a boolean, or at bare minimum a rigid Breaking: title prefix — a convention so greppable it functions as structure. Burying breakage in paragraph three is how automated bumps ship outages; the API changelog guide covers in-band signals like the RFC 8594 Deprecation and Sunset headers for the same reason.
• Full content, not teasers. A feed item that truncates to "We shipped some improvements… read more" forces every consumer back to scraping HTML — the thing feeds exist to prevent. Put the whole entry in the feed.

llms.txt: a map for agents

llms.txt is an emerging convention (proposed in 2024): a plain-markdown file at the root of your site that tells language-model tools what the site is, where the important surfaces live, and how to use them — the same spirit as robots.txt, but oriented toward helping agents rather than fencing crawlers. For a product site, a good one lists: what the product does, where the docs and OpenAPI spec live, the changelog's feed URLs, rate limits, and any rules of engagement.

Two honest caveats. First, it's young: adoption is real but uneven, and no one is obliged to fetch it. Second, it's not magic — it works exactly as well as the surfaces it points at. An llms.txt that links to a JavaScript-only changelog has documented a dead end. Treat it as the cheap final step after the feeds and API exist: ten minutes of markdown that saves every visiting agent a scraping session.

Machines that write changelogs

The traffic goes both ways. The same structure that lets software read your changelog lets software help write it: your CI posting the entry at the end of a deploy (the GitHub Actions guide shows the pattern), a release webhook mirroring GitHub Releases into your hosted page, a script piping generated draft notes into a review queue. The requirements are the mirror image of the reading side: token auth, a JSON API for create/update, machine-readable errors, and — if agents are a real audience for your tool — an onboarding path that doesn't dead-end in a CAPTCHA. The rule from the automation guides still applies: machines move the text, humans decide what it says. A pipeline that publishes unreviewed generated prose is machine-written in the bad sense.

Anti-patterns that blind your machine readers

• The widget-only changelog. Updates that exist solely inside an in-app popover have no URL, no feed, and no crawlable text — invisible to bots, scripts, and search alike (the changelog SEO guide covers the search half). Widgets are a fine mirror; they can't be the canonical home.
• Screenshot and PDF release notes. Popular with mobile games and enterprise vendors; unreadable by everything discussed on this page, and by screen readers too.
• Truncated or partial feeds. Teaser-only items, or a feed that carries 3 of your last 50 entries, force consumers back to HTML scraping.
• Unstable GUIDs. Regenerating IDs on every publish (a common static-site misconfiguration) re-notifies every subscriber about your entire history. IDs are forever.
• Prose-only breakage. If the only signal that v3 breaks the API is a paragraph a human must read, every automated consumer bumps into it blind.
• Ambiguous dates. "3/4/2026" means two different days on two sides of the Atlantic. Machines don't guess well, and neither do humans.

Two audiences, one source

None of this means writing a robot changelog. It means the opposite: write clear, human entries — symptom-named fixes, reader-benefit features, honest breaking-change warnings — and let the fields carry the metadata (date, tag, ID, URL) so machines never have to parse your prose to learn what kind of change happened when. Structure and voice are not in tension; the structure is precisely what frees the prose to be human.

How Wakelog handles this

We built Wakelog agent-and-script-first, so every rung of the ladder comes free with each project: an RSS feed and a JSON Feed, a public list API with tags, ISO dates, stable permalinks and per-entry IDs, and a changelog.md export in Keep a Changelog format so nothing is locked in. The write side is fully scriptable too — token-authed JSON API, a one-file CLI, GitHub/GitLab release webhooks, and an OpenAPI spec; our own llms.txt maps it all, and the entire lifecycle from signup to first post works with three curl calls, no email or CAPTCHA — so a CI job or an AI agent can run a changelog end-to-end.

Start your free changelog   Next: automate it from CI →

Related guides

• API changelogs: announcing changes developers will actually see
  Your consumers are programs. What counts as breaking, how to publish a deprecation policy, and how to announce changes in channels machines and humans both watch.
• Vendor changelog monitoring: keeping up with what your dependencies change
  The flip side of every other guide here: reading changelogs, not writing them. Bots, feeds, in-band signals, severity triage, and a vendor register that outlives one person’s feed reader.
• AI model changelogs: announcing updates your users can’t diff
  A model update changes behavior, not features. Pinned snapshots and loud alias moves, evals as evidence, the silent-swap trap, and retiring versions without burning users.

Last updated 2026-07-27 · All guides