Sync, drift & the changelog
A completed scan refreshes the collection. Contracts retain the consumer-facing endpoints, fields, and rules you reviewed. Review any source drift before syncing a contract and publishing its artifacts.
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:
Alert | What it means | Real example |
Breaking | The source changed in a way that violates the promise consumers depend on | Billing API removed |
Drift | The source moved away from the contract — not necessarily breaking, but no longer matching | Auth Service added required |
Sunset warning | An endpoint the contract depends on is scheduled to go away, with a countdown | Sunsets in 38 days: |
Review each drift item and decide which changes belong in the contract. Dismissing a notification does not publish new artifacts. Sync updates the contract content; publication is a separate action.
A contract in Elva cannot silently rot. The only way it drifts is loudly — with a named endpoint, a described change, and a one-click path back to sync.
Version history: every promise, on the record
A successful contract publication records a version. Review the version and each publishing destination's result to understand what consumers can access.
After syncing, review the updated contract and obtain any required approval again. Content changes can invalidate an approval made against an earlier draft.
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.
Drift detection is the payoff of building contracts on top of the living catalog: because collections rebuild from your repos on every scan, the contract is compared against what you actually shipped — not against what someone remembered to update.
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.
Example: an upstream field becomes required
Your collection adds a required shippingAddress to POST /orders. Review whether external consumers already send that field. If you adopt the change, sync it into the contract, inspect the breaking-change finding, and follow the configured policy and approval flow. Publish only when the consumer-facing change is ready; a fresh collection scan alone does not update the published MCP server.
On this page
- Sync, drift & the changelog