43 Sunsets · AI agent skills · documentationAPI Breaking-Change Detector
Give it two versions of your OpenAPI 3.x or Swagger 2.0 spec (JSON or YAML) and get every breaking change, plus the risky ones — rated from the consumer’s point of view, with a semver recommendation, a client migration table and a paste-ready changelog draft. Static analysis only.
Get it on Agensi — $12One-time purchase · works with SKILL.md-compatible agents (Claude Code, Cursor and others — the Agensi page shows the current list).
How to use it 3 steps
- Get both spec versions: the one currently deployed (OLD) and the proposed one (NEW). JSON or YAML, OpenAPI 3.x or Swagger 2.0.
- Give your agent the skill (Agensi shows the install step for your agent), provide both specs and ask, for example:
Compare the attached v1.yaml and v2.json specs. Tell me what will break for our mobile app users and what to put in the release notes. - Read the verdict and the migration table first, then paste the changelog draft into your release notes and adjust wording.
What the report contains
- Verdict — counts of BREAKING / RISKY / DEPRECATION / SAFE — and a semver recommendation (MAJOR / MINOR / PATCH) with the reason.
- Migration table your consumers can act on: severity, endpoint & exact spec location (JSON path), what changed, what consumers must do.
- Which side breaks for each breaking change: request writers or response readers.
- Changelog draft ready to paste, plus a “not breaking (so no one panics)” section.
- Honest verdicts — a fully compatible diff is told it is compatible; no invented findings.
Illustrative excerpt — this is the report shape, not output from your specs:
API Change Report — User Care API 1.2.0 → 2.0.0 Verdict: BREAKING — 2 breaking, 1 risky, 0 deprecations, 1 safe Semver recommendation: MAJOR — removal of login fields | # | Severity | Endpoint & location | What changed | What consumers must do | | B1 | BREAKING | POST /login → responses.200 schema.properties.token | removed (was: string) → new: access_token | read access_token from the response body | | B2 | BREAKING | GET /profile → security (apiKey) | in: query (api_key) → in: header (X-API-KEY) | send the key in the X-API-KEY header |
The 10 categories
| # | Category | Examples |
|---|---|---|
| 1 | Removed & renamed | Paths, operations, parameters, response fields |
| 2 | Required-ness | The optional-to-required trap |
| 3 | Type & format | Type changes, tightened constraints |
| 4 | Enums | Including response enums that break exhaustive switches |
| 5 | Response shape | Removed fields, changed status codes, content-type switches |
| 6 | Auth & security | New scopes, moved API keys, changed schemes |
| 7 | Pagination, filtering, sorting | Silent behavior changes in list endpoints |
| 8 | Deprecations & sunsets | Announced removals and dates |
| 9 | Additive changes | Verified as truly safe — collision check included |
| 10 | Server & metadata | Host and base-path changes (e.g. /v1/ → /v2/), content-type defaults |
RISKY is a first-class category: new response enum values, changed defaults, new error codes — technically compatible, commonly catastrophic. A naive diff calls these safe.
What it does not do
- It reviews the machine-readable contract only. It does not call your API and never fetches URLs referenced in the spec.
- It cannot see runtime behavior that the spec does not describe (undocumented fields, server-side validation, rate limits).
- Test against a staging environment before releasing — the report is a review, not a guarantee.
FAQ
Which formats are supported?
OpenAPI 3.x and Swagger 2.0, as JSON or YAML. Two full specs are needed; a partial diff or a screenshot is not enough.
How does it decide between BREAKING and RISKY?
BREAKING = an existing, spec-conforming client stops working (removed field, optional→required, changed auth). RISKY = the client still works today but is likely to break in practice (new enum value in a response, changed default, new error code).
Is my spec private?
The skill is a set of instructions for the agent you already use; nothing is sent to 43 Sunsets. What leaves your machine is governed by your agent’s own privacy settings.
Refunds?
Purchases are covered by Agensi’s 30-day refund policy under Agensi’s terms; refunds are handled by Agensi, not by 43 Sunsets.
Also by 43 Sunsets: n8n Production-Readiness Auditor · all products · [email protected]
Not affiliated with the OpenAPI Initiative, The Linux Foundation, or SmartBear Software. “OpenAPI” and “Swagger” are trademarks of their respective owners, used here only to describe compatibility.