A safer API release starts here.
Compare two OpenAPI contracts, understand the impact, and bring compatibility checks into your development workflow.
01. Run your first comparison
Open the workspace and load the Users API example, or paste your own specifications. Baseline is the contract consumers use today. Candidate is the version you plan to release.
Open comparison workspace →02. Understand compatibility
Compatibility is evaluated from the consumer's perspective. A valid specification can still break an existing client. Review both the classification and the affected schema location.
| CHANGE | CLASSIFICATION |
|---|---|
| Operation removed | Breaking |
| Optional request parameter added | Non-breaking |
| Response enum value added | Needs review |
03. Use the CLI
The Java CLI invokes the same comparison core without sending contracts over the network.
java -jar oasfuse-cli.jar compare \ --baseline users-v1.yaml \ --candidate users-v1.1.yaml \ --format markdown --output report.md \ --fail-on breaking
Exit code 0 means the chosen threshold was not met, 1 means findings met it, and 2 means invalid input or a comparison error.
04. Add a pull-request check
Use the CLI on a GitHub-hosted runner. Keep production secrets and self-hosted deployment runners away from untrusted pull-request code.
permissions:
contents: read
jobs:
compare:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: java -jar oasfuse-cli.jar compare ...Security & privacy by intention
Comparisons are stateless and inputs are not saved by the application. External $ref values are rejected and never fetched. Public deployments must enforce body, concurrency, and rate limits.
This is a design claim backed by the repository implementation, not a third-party audit or a guarantee about a host you do not control.