Skip to content
Release notes widget

The changelog inside the system they already use

Shipped a version? The badge lights up in your customer’s app, the banner tells them what changed and the read is recorded, customer by customer. No newsletter that nobody opens.

  • Badge, banner and changelog
  • Internal or external audience
  • Acknowledgement report
Three pieces

Notice, reading and history

The same snippet delivers all three, and you choose which ones to use.

Version badge

It sits next to the version number in your system, or floating in a corner, and lights up when there is news nobody has seen.

Release banner

It opens telling what changed. When acknowledgement is required, it only lets go after the person scrolls to the end and confirms.

Browsable changelog

The full history of that product’s versions, with date and content, inside your app.

Audience

Not everything that changes is for the customer to see

Each note has one audience: internal, external or both. The widget instance declares the audience it shows, and the server filters the notes by it.

  • Internal, external or both audiences, note by note
  • Acknowledgement split by environment: a modal inside the app, a banner inside the widget
  • A report per note: the users at each customer who confirmed they read it, with the date
  • A queue per user: whoever joined later sees what they missed, in the right order
  • Notes tied to the product, for those who sell more than one system
  • Internal notes aimed at product roles: the note reaches whoever has one of them, and whoever declares no role keeps seeing everything
  • Portuguese, English and Spanish in the same widget

Proof that you told them

When the customer says "nobody told me", the report shows the date they read and confirmed. It serves the commercial conversation and an audit alike.

How to publish

From the pipeline to the customer

  1. 1

    Write the note

    In the dashboard, with a rich editor — or let your deploy write it for you.

  2. 2

    Publish through the API

    One idempotent call per product and version, made by your CI at deploy time.

  3. 3

    Choose the audience

    Internal, external or both, and whether that note requires acknowledgement.

  4. 4

    Track the reading

    See, for each note, who at each customer confirmed reading it and when.

The release notes API is part of the public API, with a scoped key.

Why it matters

What you ship has to get used

Adoption of what was built

A feature the customer does not know exists creates no value and justifies no further budget.

Fewer repeat tickets

A screen change announced right away avoids the "the button is gone" queue the day after the deploy.

Communication with proof

A contract change, a new price or the end of a feature are recorded as announced and read.

Questions about the release notes widget

Do I need to use the support widget as well?

No. The two are independent: you can put only the release notes one in your system, using the same kind of key.

Does required acknowledgement block the use of the system?

It blocks only the banner, and only until the person scrolls the text and confirms. You decide which notes require it — for most of them, it is not worth it.

Can I publish straight from my deploy?

You can. The call is idempotent per product and version: if the pipeline runs twice, the note is not duplicated.

Does the customer see internal notes?

The widget instance declares the audience it shows — external by default — and the server filters the notes by that audience.

Tell them where they already are

Put the badge in your system and see the difference on the very next version you ship.