About this tool
Write a Keep a Changelog style API release note with Added, Changed, Deprecated, Removed and a SemVer version bump.
An API changelog generator turns a list of changes into a release section formatted to the Keep a Changelog 1.1.0 convention, and works out the Semantic Versioning 2.0.0 bump those changes require. It is aimed at teams who publish a versioned HTTP API and need consumers to see exactly what broke, what was added and what is being sunset. Removals and any change you mark as incompatible force a major bump; new functionality gives a minor bump; bug and security fixes give a patch.
Open API Changelog Generator on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
The version is derived from the change types, not guessed by hand.
Incompatible items are prefixed BREAKING and counted in a callout at the top.
Output pastes straight into CHANGELOG.md, including the compare link between the two tags.
Added, Changed, Deprecated, Removed, Fixed and Security. Keep a Changelog 1.1.0 prints them in that order under each version heading, and every heading carries the version number and an ISO 8601 release date.
Whenever the change is not backwards compatible for an existing client — removing an endpoint or field, renaming a field, tightening validation, or changing an error code a client branches on. Semantic Versioning 2.0.0 reserves MAJOR for incompatible API changes, MINOR for backwards-compatible additions and PATCH for backwards-compatible fixes.
There is no universal rule, but a common practice is to announce the deprecation in a minor release with a dated sunset, keep the old behaviour working for at least one full major version, and return a `Deprecation` and `Sunset` response header (RFC 8594 defines `Sunset`) so clients can detect it programmatically.
Semantic Versioning says anything may change at any time while the major version is 0, so a 0.x API carries no compatibility promise. Teams that want stability signals before 1.0.0 usually still bump the minor for breaking changes and the patch for fixes, and say so in the changelog header.