Build an AI Changelog Generator with Telnyx AI Inference

Most developers have written a changelog by staring at a wall of commit messages and trying to remember what actually mattered.

Some commits are user-facing. Some are internal cleanup. Some are merge commits. Some are useful only if you already know the project. Turning that stream into a readable release note takes judgment.

The changelog-generator-python example shows how to build a small Python API that uses Telnyx AI Inference to turn commit messages or git diffs into structured changelog JSON.

Code:

What the example builds

The app is a Flask service with four core routes:

• POST /generate creates a changelog from a list of commit messages
• POST /generate/from-diff creates a changelog from a git diff
• GET /changelogs lists recently generated changelogs
• GET /changelogs/<id> fetches a generated changelog by ID
• GET /health returns basic service status

The output is structured JSON, not just prose. A successful response can include:

• version
• date
• grouped sections
• section items
• a one-sentence summary
• generated_at
• commit_count

That makes the result useful beyond a demo response. You could render it in docs, store it in a release database, add it to a pull request, or pass it to another publishing workflow.

Why changelog generation is a good AI workflow

Changelogs are a natural fit for LLMs because the task is not only summarization. It also involves classification.

The app asks the model to group release entries under headings such as:

• Features
• Bug Fixes
• Improvements
• Breaking Changes
• Documentation
• Other

It also asks the model to drop merge commits and trivial chore entries, then write concise bullets in a release-friendly style.

That is useful because the goal of a changelog is not to repeat your git log. The goal is to explain what changed in a way another developer can quickly understand.

How the app uses Telnyx AI Inference

The app sends requests to:

POST /v2/ai/chat/completions

The default model in .env.example is:

AI_MODEL=moonshotai/Kimi-K2.6

For commit-based changelogs, the app builds a prompt from:

• commit messages
• optional release version
• optional repository name

For diff-based changelogs, it sends a truncated diff and asks the model to return grouped release notes.

The app expects JSON back. If the model returns valid JSON, the API stores the generated changelog in memory and returns it with an ID. If the model returns non-JSON text, the app returns the raw result so the developer can inspect it.

Run the example

Clone the examples repo:

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/changelog-generator-python

Create your environment file:

cp .env.example .env

Add your Telnyx API key:

TELNYX_API_KEY=your_telnyx_api_key
AI_MODEL=moonshotai/Kimi-K2.6
HOST=127.0.0.1

Install dependencies and start the app:

pip install -r requirements.txt
python app.py

Check the server:

curl http://localhost:5000/health

Generate a changelog from commit messages:

curl -X POST http://localhost:5000/generate \
  -H "Content-Type: application/json" \
  -d '{
    "version": "v1.4.0",
    "repo_name": "billing-service",
    "commits": [
      "feat: add Stripe webhook retry with exponential backoff",
      "fix: correct tax calculation for EU VAT exemption",
      "docs: update API reference for invoice endpoint",
      "refactor: extract currency formatter into shared util"
    ]
  }' | python3 -m json.tool

Generate a changelog from a diff:

curl -X POST http://localhost:5000/generate/from-diff \
  -H "Content-Type: application/json" \
  -d '{
    "version": "v1.4.1",
    "diff": "diff --git a/app.py b/app.py\n+def retry_send(message, retries=3):"
  }' | python3 -m json.tool

Where this pattern can go

This is intentionally small, but the pattern is useful in real developer workflows.

You could extend it to:

• generate release notes from a GitHub pull request
• draft changelog entries during CI
• compare commits between two tags
• open a docs PR with generated release notes
• summarize SDK changes by language
• create a human review step before publishing

The important part is the interface. The model returns structured data, so your app can decide what to publish, where to store it, and how much human review is required.