> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Orbit changelog: product updates and API changes

> Track Orbit product updates, API changes, and new features on the canonical, always-current release history — and see how entry kinds and maintenance of this page work.

Orbit's complete, always-up-to-date changelog lives on the app site. It is the
single canonical, paginated view of every release — features, improvements,
and fixes — so it never drifts out of date. This page is pointers only: it
links to that history and explains how entries are classified. There is no
hand-maintained digest here to refresh, and no generated snapshot to rot.

## How the changelog works

The full release history is published on
[orbit.devotel.io/en/changelog](https://orbit.devotel.io/en/changelog), with
one entry per release and the release date on each item. Subscribe to changes
over the site RSS feed ([/changelog/rss.xml](https://orbit.devotel.io/en/changelog/rss.xml))
if you want new entries pushed to you instead of polling the page.

> **[View the full changelog →](https://orbit.devotel.io/en/changelog)**
>
> Open orbit.devotel.io/en/changelog for the full published release history.

## Kinds of change

Every release entry is one of four kinds, so you can scan for the class you
care about:

| Kind | What it means |
| - | - |
| **Feature** | A new capability — an endpoint, a channel, a dashboard workflow. |
| **API change** | A change to the API contract: a new or altered field, parameter, or response shape. Breaking API changes always link to the affected endpoint page, so you can see the exact contract change before you upgrade. |
| **Deprecation** | Something is scheduled for removal. The entry carries the sunset date and links to the replacement, if one exists. |
| **Dashboard surface** | A change to the dashboard UI — a new screen, a reorganized settings page, a new report. |

## Anatomy of a release entry

Each entry on the canonical changelog is built the same way, so once you know
the anatomy you can scan any release in seconds. An **API change** entry looks
like this:

> #### Opt-Out Lists API is now paginated
>
> **API change · SMS API — June 28, 2026**
>
> The **list opt-out lists** endpoint (`GET /messaging/opt-out-lists`) used to
> return *every* opt-out list in your account in a single response. …
>
> **What you need to change.** This is a backward-incompatible change for
> accounts with more than 50 opt-out lists. A single call no longer returns
> your entire collection — it returns the first 50, and the rest are reachable
> only by following the cursor. …

Three things to look at, in order:

1. **The kind tag and surface.** The first line under the title names the kind
   (Feature, API change, Deprecation, or Dashboard surface) and the surface it
   touches (SMS API, Voice, Dashboard). Read the tag first — it tells you
   whether anything in your integration has to move.
2. **The body.** The first paragraphs state the change plainly: the endpoint
   path when the entry is an API change, the before/after behaviour, and the
   scope of accounts it affects.
3. **The action block.** **API change** entries name the exact contract change
   and, when the change is backward-incompatible, end with a *what you need to
   change* step. For API changes the entry links the affected endpoint to its
   page in the [API reference](/api-reference), so you can open the current
   contract before you upgrade.

A **Deprecation** entry adds one more thing to that checklist: a **sunset
date** in the body, with a link to the replacement surface when one exists.
The date it carries is the deadline after which the old surface may be
removed — plan against that date, not the day you read the entry.

## Consume the changelog programmatically

The RSS feed at
[/changelog/rss.xml](https://orbit.devotel.io/en/changelog/rss.xml) is the
machine-readable counterpart to the page. Fetch the latest items with curl:

```bash theme={null}
curl -s https://orbit.devotel.io/en/changelog/rss.xml
```

Every `<item>` in the feed carries:

* `<title>` — the entry headline.
* `<link>` and `<guid>` — both point at the entry's anchor on the changelog
  page (for example `/en/changelog#2026-09-12-voice-ai-…`), so a `<guid>` you
  stored stays a valid deep link.
* `<pubDate>` — the release date.
* `<description>` — a short summary; the entry's full body follows as HTML in
  `<content:encoded>`.
* `<category>` — the entry kind (`feature`, `improvement`, `fix`, `breaking`,
  `deprecation`), so your reader can filter for the class you care about
  without parsing the body.

Most feed readers (Slack's `/feed subscribe` built-in command, Feedly,
NewsBlur, a self-hosted reader) accept the URL as-is — paste
`https://orbit.devotel.io/en/changelog/rss.xml` and the entries arrive as new
releases ship. To route only API changes and deprecations — the two classes
that can require work on your side — filter on `<category>` and match
`breaking` or `deprecation`; point your team's automation (a small script or a
reader filter) at those two values and let features flow to everyone.

Point the same feed at your own alerting channel and treat a `breaking` or
`deprecation` item as the trigger for the migration workflow below — that is
how breaking API changes reach an integrator first, instead of at upgrade
time.

## From deprecation to migration

When a `deprecation` entry lands — or when you plan an upgrade and want the
list of `breaking` entries since your current version — work through the same
short workflow each time:

1. **Open the entry** from the feed `<link>`. Note the **sunset date** it
   carries — that is the removal deadline; everything else is scheduling
   around it.
2. **Open the affected endpoint page.** API-change and deprecation entries
   link the endpoint straight into the [API reference](/api-reference), so
   the current request/response contract is one click away.
3. **Follow the migration notes in the entry body.** Each deprecation entry
   spells out the replacement surface (when one exists) and the before/after
   behaviour, so the code change is spelled out rather than discovered.

For a deprecating endpoint, requests to the old path keep working until the
sunset date — the entries are written so a reader can schedule the switchover
instead of reacting to a removal.

## How this page is maintained

Earlier revisions of this page carried a short, hand-picked digest of recent
releases. That list had to be refreshed manually and would slowly lie, so the
digest was removed — the canonical changelog above is the only list of
"latest releases," and it is fed automatically from the shipped release notes,
not assembled by hand. If you reach this page from somewhere else in the docs,
fix the link to point straight at the canonical changelog rather than asking
for the digest to come back.

If you are a maintainer: the content generator that used to produce the
in-page snapshot was retired, and the page is now static pointers plus the
kind taxonomy. There is intentionally nothing to regenerate.

## Read further

For recurring integration questions the [FAQ](/reference/faq.md) answers the
common ones; for the complete release timeline open the
[product changelog](https://orbit.devotel.io/en/changelog).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.