Sync, drift & the changelog

Every API program has the same dangerous gap: the contract you promised and the code you shipped, slowly growing apart. Elva closes it by construction. Because contracts are composed from live collections, Elva continuously compares the promise against the source — and the moment the code moves, the contract raises its hand. Loudly.

Inside a contract

Open any contract and the header tells you the state of the promise before you read a single row: the name, the current version badge (V1.0.0), the visibility badge, and — most importantly — the sync indicator: a green “Last synced: 12 days ago” when all is well, a red “Out of sync” when it is not. Edit and Publish sit top-right, and the workspace splits into five tabs: Overview, Intelligence, Changelog, Endpoints, and Settings.

The Overview tab is the contract’s dashboard:

• Published To — every live artifact (the hosted OpenAPI spec file, the MCP server) with its version and copy/open shortcuts.
• Source API collections — each collection feeding the contract, with how many of its endpoints are in the contract and a per-collection Synced or Drift badge. A contract drawing 21 endpoints from Notifications, 12 from Billing, 7 from Users, and 3 from Integrations shows exactly that.
• The stats rail — endpoints, stakeholders, source collections, and publish targets at a glance.
• Stakeholders — the invited people with their roles, searchable and editable in place.

When the code moves: active alerts

The moment a source collection changes in a way that affects the contract, the overview grows a red banner — “2 active alerts: source drift and breaking change detected” — with a Review changes button, the drifting collection gets its badge, and the Changelog tab lights up. Three kinds of alerts land there:

Each alert names the exact endpoint with a method-and-path badge and offers two actions: dismiss it (you have handled it out of band) or Sync — pull the change into the contract and move forward deliberately. What a breaking change is allowed to do — block the next publish, demand an acknowledgment, or just notify — is whatever you chose as the contract’s governance policy.

Version history: every promise, on the record

Below the alerts, the Changelog tab keeps the contract’s full version history. Every publish creates a version entry with its status badge (the live Public version versus Outdated predecessors), the author who published it, and the date — and each version expands for the details. v1.2.0 by one engineer in June, v1.1.0 and v1.0.0 before it: the whole life of the promise, attributable and auditable.

That record answers the questions that usually eat an afternoon: what did we promise the partner in March, who approved it, and what changed since? Scroll, don’t archaeology.

Triage from the portfolio

You do not have to open contracts one by one to find trouble. On the API Contracts list, a drifting contract’s card is flagged with a red Drift badge and outline, right next to its healthy Public and Private siblings. Filter by status and the portfolio becomes a work queue.

Where to go next

Governance & stakeholders

The policy that decides what an alert is allowed to block, and the people it notifies.

The living API catalog

The always-current source of truth that makes contract drift detectable in the first place.