Developers · Changelog

Release notes, after v1 lock.

A public changelog is most useful when there's a stable API to write change notes against. While v1 is still settling, we send change notes directly to integrating customers — and we'll fold that history into this page the day v1 ships.

Public changelog Q4 2026
When it launches

How we'll publish.

The shape of what we're building, with enough detail to decide whether to wait for us or to design around the gap in the meantime.

  • Reverse chronological
    Most-recent release at the top. Versioned. Searchable. Linked to the relevant API reference sections and SDK release tags.
  • Categorized entries
    Added · Changed · Deprecated · Removed · Fixed · Security. The standard Keep-a-Changelog shape — no surprises.
  • Breaking changes
    Always called out at the top of any release that contains one. With a migration note, a deadline, and an offer to pair on the upgrade.
  • Network and standards updates
    When CommonWell, TEFCA, or NCPDP ship a change that affects how we behave, you see it here. We don't bury upstream-driven changes in our own changelog.
In the meantime

Get early access or talk to an engineer.

Active partners receive every change note directly via shared engineering channels and email. We don't gate changelog visibility — we just send it where it'll actually be read.