Overview

API change detection compares a re-fetched API specification against your project's existing endpoints and surfaces what changed — new, modified, removed, and breaking endpoints. A reviewer approves or rejects the changes; approving imports them as new versions of the affected endpoints. Explore the capability at API change detection.

Before you begin

You need a project whose endpoints were originally imported from an API spec (see Import and discover endpoints).
Navigation path: open Project Settings for the project, then the Change Detection tab. To compare against saved spec URLs, add them as Monitored URLs in project settings first.
Approving or rejecting requires the spec-approval capability; both actions are audit-logged.

Step 1 — Check for API changes

In Project Settings, open the Change Detection tab. The Check for API Changes panel appears.
Choose a check method with the radio buttons:
- Check Monitored URLs (N active) — re-fetches the spec URLs configured for the project. Each monitored URL is listed with its type and last-checked time. (Disabled if none are configured.)
- Check Custom URL — reveals an API Specification URL field plus an API-type dropdown: Auto, REST, SOAP, or GraphQL. Paste a spec URL (Swagger/OpenAPI, WSDL, GraphQL, etc.).
Click Check for Changes. While it runs the button shows Checking....
When it finishes, a message reports the result — e.g. "Found changes in 1 of 2 URL(s)" or "No changes detected in 2 URL(s)".

Step 2 — Expand the Change Summary

If changes were found, a Change Summary section appears at the bottom of the panel with per-type counts and breaking badges.

Click the summary header to expand it. Studio loads the details and shows tiles for Total Changes, New Endpoints, Modified, and Removed, plus a red banner if breaking changes exist.
The expanded view lists the affected endpoints grouped as New Endpoints, Modified Endpoints (with a Breaking tag where relevant), Removed Endpoints, and Breaking Changes (with description, impact, and severity).
Click View Full Details & Review Changes to open the review dialog.

Step 3 — Review API changes

The Review API Changes dialog opens (the proposed version shows as a chip in the header). It has a Change Summary block — Total, New, Modified, Removed, and a breaking-changes callout — and up to four tabs:

Tab	What it does
New Endpoints (N)	Each new endpoint with a checkbox (selected by default), its name, and `METHOD path`. Untick any you don't want to import.
Modified (N)	Each modified endpoint with a checkbox and a Modified or Breaking tag. Expand a row (chevron) to see the Old Value / New Value diff.
Removed (N)	Removed endpoints, listed for awareness (not selectable).
Breaking Changes (N)	Shown only when breaking changes exist: change type, endpoint, description, impact, and severity.

Step 4 — Read the Old/New diff

Inside an expanded Modified row, the diff viewer shows each change as a card:

A Breaking or Non-Breaking badge plus the change description.
Old Value (left) and New Value (right) rendered as formatted JSON so you can see exactly what changed in the schema.

Step 5 — Approve or reject

Click Approve & Import to import the selected New/Modified changes as new versions of those endpoints. The button shows Approving... while it runs, then confirms "Changes approved and imported successfully."
Click Reject to discard the pending changes. A confirmation warns "Are you sure you want to reject these changes? This action cannot be undone." — confirm to record the rejection.
Cancel closes the dialog without deciding.

Step 6 — Manage endpoint versions

Approved changes create versioned endpoints. On an endpoint, use the Version selector to:

See the version history in the dropdown, each labeled Active or Deprecated.
Activate a version by selecting it — it becomes the active version for that endpoint.
Deprecate an older version so consumers know not to rely on it.

This keeps a full change history per endpoint.

Troubleshooting / Notes

"Check Monitored URLs" is disabled — no active monitored URLs are configured; add them in project settings or use Check Custom URL.
Auto type fails on a custom URL — pick the specific API type (REST / SOAP / GraphQL) in the dropdown and re-check.
"Pending change ID is required to load change details" — reopen the review from View Full Details after re-running the check.
Can't approve or reject — approval/rejection needs the spec-approval capability; ask an administrator.
Review Breaking Changes first — they may affect existing clients and tests; re-run or regenerate tests for changed endpoints after importing. See Generate endpoint test cases.

API Change Detection