See exactly when your OpenAPI contract changes

Register a published OpenAPI spec. Cryonel re-checks it daily, diffs every version against the last one, and alerts you with the exact severity and location of each change.

The preview uses sample data and mirrors the real severity, history and notification experience.

The problem with uptime monitoring

A classic uptime check confirms your API responds with 200 OK. It says nothing about whether the shape of that response just changed underneath your integrators. An API can be "up" and still be broken for every client depending on a field that quietly disappeared.

// yesterday
{"user_id": 123}

// today — still 200 OK, still "up" — but broken for anyone reading user_id
{"userId": "123"}

Block contract breaks before deployment

The Cryonel CLI is available on npm and works directly in GitHub Actions today. It compares the base and candidate files inside your runner, applies repository-specific severity and ignore policy, writes a readable job summary, and returns a failing exit code when policy is violated. Specs are parsed locally and are not uploaded to API Guard.

npx @semihbugrasezer/cryonel diff openapi-main.yaml openapi-current.yaml

Read the public CLI and CI setup guide or use the $299 implementation service for a documented installation.

How it works

• 1Register an OpenAPI spec — a URL we re-fetch automatically every day, or paste a version manually any time.
• 2The first version becomes your baseline — nothing to compare yet.
• 3On every later check, we parse and diff the new version against the last one.
• 4Every difference is classified into one of four severities: breaking, potentially breaking, non-breaking, or documentation-only — never collapsed into one vague "changed" bucket.
• 5Breaking and potentially-breaking changes trigger email alerts. Pro can also notify Slack or a signed JSON webhook. Full history stays in your dashboard.

What counts as breaking

Not every schema change is equal, and treating them all the same is exactly what makes people ignore alerts. A few examples of what Cryonel API Guard classifies as genuinely breaking: a required field added to a request, a field removed from a response, a data type changed, an enum value removed, a 2xx response removed entirely. A new optional field or a new response code, on the other hand, is non-breaking — it doesn't stop a well-behaved client from working.

Built on the same standards as our free tools

API Guard's diff engine is a natural extension of the OpenAPI Spec Validator already on Cryonel — same OpenAPI 3.0.x/3.1.x parsing, same standards-first approach. See exactly what's stored and why in Technical Transparency.

Product resources

Review the currently available integrations, implemented security controls, and the public changelog. Planned features are kept separate from shipped behavior.

FAQ