# API Change Detection

> Detect when an imported API spec changes, review new, modified, removed, and breaking endpoints in a diff, then approve and import the changes as new endpoint versions.

Source: https://totalshiftleft.ai/help-center/product-documentation/api-change-detection

## 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](/features/analytics-monitoring/api-change-detection).

## Before you begin

- You need a **project** whose endpoints were originally imported from an API spec (see [Import and discover endpoints](/help-center/product-documentation/endpoint-import-and-discovery)).
- 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

1. In **Project Settings**, open the **Change Detection** tab. The **Check for API Changes** panel appears.
2. 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.).
3. Click **Check for Changes**. While it runs the button shows **Checking...**.
4. 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.

1. 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.
2. 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).
3. 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](/help-center/product-documentation/ai-generated-tests).

## Related articles

- [Import and discover endpoints](/help-center/product-documentation/endpoint-import-and-discovery)
- [Endpoint management](/help-center/product-documentation/endpoint-management)
- [Regression analysis](/help-center/product-documentation/regression-analysis)
- [Audit Logs](/help-center/product-documentation/audit-logs)