Skip to main content
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, with one entry per release and the release date on each item. Subscribe to changes over the site RSS feed (/changelog/rss.xml) if you want new entries pushed to you instead of polling the page.

View the full 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:

​
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, 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 is the machine-readable counterpart to the page. Fetch the latest items with curl:
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, 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 answers the common ones; for the complete release timeline open the product changelog.