Turn a Trello Board Into a Weekly Changelog

How to get a reliable weekly changelog out of Trello: which signal marks work as done, how to map boards and labels to product areas, and how to handle backfill and webhooks.

Soobrief Team — Product & Engineering, Sooapps · 2026-08-12

In short

A Trello board already contains a changelog — the missing piece is a rule that decides when a card counts as shipped. Pick one signal (a Done list, or a specific label), map board and label to product and category, and read cards by the timestamp they entered that state. Once that mapping exists, the weekly changelog is a query, not a writing task.

A Trello board is already a changelog. Every completed card is a record of something that shipped, with a timestamp, a title, and — if the board is organized at all — an implicit product area. The reason nobody builds a Trello changelog by hand is that the extraction is tedious enough that it never survives a busy week.

The extraction is mechanical, though. Producing a Trello changelog on a weekly rhythm takes three decisions, made once.

Decision 1: what "done" means

This is the decision that determines whether the output is trustworthy, and it is the one most teams leave ambiguous.

Pick exactly one signal:

Signal	Works well when	Watch out for
A specific list (`Done`, `Shipped`)	The board has a clear left-to-right flow	Cards parked in Done that were actually abandoned
A label (`shipped`, `released`)	Cards live in several lists after completion	Labels applied inconsistently across members
Card archiving	The team archives aggressively on completion	Archiving is also used for cleanup and duplicates

The failure mode is not picking the "wrong" signal — any of the three works. It is using two at once. A team that treats both "in the Done list" and "labeled shipped" as completion will double-count some cards and miss others, and the changelog quietly becomes something people stop trusting.

Write the chosen rule down somewhere the team can see it. The rule is part of the process, not an implementation detail.

Decision 2: how boards and labels map to structure

A changelog grouped as one flat list is barely better than the board itself. The value comes from grouping, and Trello already carries enough signal to do it without judgment:

Board → product area. One board per product or major surface is the common case, and the mapping is direct.
List or label → category. bug, feature, infra, design — whatever vocabulary the team already uses.
Card title → the changelog line, ideally lightly rewritten as an outcome.

Two properties make this mapping worth formalizing. It is stable, so the same card always lands in the same place, which means two consecutive weeks are directly comparable. And it is explicit, so when something lands in the wrong section the fix is a mapping change, not an argument about interpretation.

If your boards do not currently support a clean mapping, that is worth knowing. A board that cannot be mapped to product areas is usually a board that is also hard for humans to read.

Decision 3: backfill versus ongoing sync

These are genuinely different operations and conflating them causes trouble.

Backfill is a one-time historical read. You connect a board and ask for everything completed in the last N days. It uses Trello's REST API, pages through card actions, and reads the timestamp of each card's transition into the completed state. Backfill is how you get a useful first changelog immediately instead of waiting a week for events to accumulate.

Ongoing sync is event-driven. Trello webhooks fire on card updates, and the integration records completions as they happen. This is cheaper than repeatedly polling a board and it captures the transition time accurately rather than inferring it.

One practical detail that catches most teams setting up Trello webhooks: Trello validates the callback URL with a HEAD request before it will create the webhook. The URL must be publicly reachable over HTTPS at registration time. A localhost API cannot complete webhook setup — you need a public tunnel during development, and the real public origin in production.

A second detail: cards move backwards. Something lands in Done on Tuesday, gets reopened Wednesday. The correct handling is to treat the most recent transition into the completed state as the completion time, and to let a card that has left the completed state drop out of the window. This is why reading current board state matters more than trusting a one-time snapshot.

Putting it together

With those three decisions made, the weekly Trello changelog is a query:

> Give me every card that entered the completed state between Monday and Sunday, grouped by board → label, ordered by completion time.

The output is a structured document. It is not yet a good changelog — card titles are written by and for the people doing the work, and a raw list of them reads like a database dump. That is where a narration pass earns its place: rewriting PROJ-4412: invite bug into a sentence a reader outside the team can use, and adding two or three sentences of context above the list.

The order matters. Structure first, from rules. Prose second, on top of already-organized data. Reversing the order — handing raw cards to a language model and asking for "a changelog" — produces something that reads fine and reorganizes itself every week, which makes consecutive weeks impossible to compare.

How Soobrief handles this

Soobrief implements exactly this pipeline for Trello. You connect a board — either through Trello authorization, which registers the webhook automatically, or by entering an API key and token manually — then select which lists count as completed. From there:

Completed cards are ingested by webhook, with backfill available for history.
Board and label map to product and category through deterministic rules, so identical input always produces identical structure.
The language model receives the already-grouped document and writes prose only. It never decides the grouping.
The result is editable Markdown, reviewed by a human before it goes anywhere.

Trello is the first fully supported source; Jira is next, with a generic provider integration after that.

Frequently asked questions

How do I know when a Trello card counts as done? Choose exactly one signal and apply it consistently — usually a specific list such as "Done" or "Shipped", or a dedicated label. Two competing signals is the most common source of missing or duplicated items.

Can I generate a changelog from multiple Trello boards? Yes. Map each board to a product area and each label or list to a category. Multiple boards then merge into one grouped changelog without per-board special casing.

Does this work for cards completed before the integration was connected? Yes, through backfill — reading historical cards by their completion timestamp. Backfill is a one-time read of past state; webhooks handle everything after connection.

What if a card is moved to Done and then moved back? Use the most recent transition into the completed state as the completion time. A card moved back out should drop from the window until it re-enters.