Key Facts
- Category
- Development
- Input Types
- textarea, select, text, checkbox
- Output Type
- json
- Sample Coverage
- 4
- API Ready
- Yes
Overview
The OpenAPI Diff Breach Detector is a specialized utility designed for API teams to compare OpenAPI or GraphQL schemas and instantly identify breaking changes. By analyzing the differences between your old and new schema versions, it generates an impact-oriented report that highlights removed fields, modified endpoints, and altered input contracts. This helps developers, architects, and QA teams catch potentially disruptive API updates before they reach production, ensuring seamless integration for frontend and mobile consumers.
When to Use
- •Before merging pull requests that modify API contracts to ensure no breaking changes are introduced.
- •When preparing a new software release to assess the impact of schema updates on existing frontend or mobile consumers.
- •During code reviews to quickly verify that GraphQL mutations or REST endpoint modifications remain backward compatible.
How It Works
- •Paste the previous version of your OpenAPI (YAML/JSON) or GraphQL SDL into the Old Schema field.
- •Paste the updated version into the New Schema field and select the appropriate schema type.
- •Enable the impact analysis option to generate a detailed breakdown of the changes.
- •The tool compares the two schemas and outputs a structured JSON report highlighting breaking changes, release risks, and impacted areas.
Use Cases
Examples
1. Catching a removed response field
Backend Developer- Background
- A developer is refactoring a user profile endpoint and accidentally removes the email field from the response payload.
- Problem
- Need to ensure the updated OpenAPI spec doesn't break existing clients relying on the email field.
- How to Use
- Paste the old OpenAPI YAML and the new YAML into the respective fields, select 'OpenAPI / Swagger', and enable Impact Analysis.
- Example Config
-
{ "schemaType": "openapi", "includeImpactAnalysis": true } - Outcome
- The tool flags a 'high' release risk and identifies that 'response 200.email' was removed, allowing the developer to fix the regression before merging.
2. Reviewing a GraphQL input contract change
API Architect- Background
- The team is adding a new 'category' requirement to the 'createPost' mutation to support a new feature.
- Problem
- Determine if adding this required field will break current frontend implementations.
- How to Use
- Input the old and new GraphQL SDL schemas, set the schema type to 'GraphQL', and run the comparison.
- Example Config
-
{ "schemaType": "graphql", "includeImpactAnalysis": true } - Outcome
- The report highlights a breaking change where a required input field was added, warning that existing mutations will fail unless updated to include the new category field.
Try with Samples
developmentRelated Hubs
FAQ
What schema formats does this tool support?
It supports OpenAPI (Swagger) in YAML or JSON format, as well as GraphQL Schema Definition Language (SDL).
What is considered a breaking change?
Breaking changes include removing an existing endpoint, deleting a response field, changing a field's data type, or adding a new required input parameter that existing clients do not send.
Can the tool automatically detect my schema type?
Yes, you can set the Schema Type to 'Auto detect,' and the tool will infer whether you are comparing OpenAPI or GraphQL definitions based on the input syntax.
What does the impact analysis include?
The impact analysis evaluates the severity of changes, categorizing them as breaking, dangerous, or non-breaking, and assigns an overall release risk level to help teams prioritize fixes.
How do I view the comparison results?
The tool outputs a structured JSON report detailing the total changes, specific paths affected, and a summary of the impact for each modification.