Catch breaking API changes before your users do

Register your OpenAPI spec. Cryonel API Guard re-checks it, diffs every version against the last one, and tells you exactly what changed and how severe it is — not just "the endpoint responded."

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"}

How it works

• 1Register an OpenAPI spec — a URL we re-fetch automatically (Pro), or paste a version manually any time (Free or Pro).
• 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 an email. 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.

FAQ