PixelOkay Local-first analysis
Tools
DEVELOPER INTELLIGENCE CONTRACT AUDIT STUDIO

API Contract Drift Detector

Compare OpenAPI contracts with real request and response captures—or compare two contract versions. Trace breaking changes, type mismatches, missing fields, and unexpected endpoints without sending data to a server.

✓ OpenAPI 3.0 / 3.1✓ Request + response validation✓ Version diff✓ Exportable findings
AUDIT WORKSPACE

API Contract Drift Detector

01

Reference API specification

OpenAPI JSON or common YAML syntax. The baseline never leaves this device.

Paste below or choose a file

Supports internal $ref, request bodies, JSON response schemas, parameters and status codes. Maximum 4 MB.

02

Captured traffic samples

Upload request/response pairs, HAR, or line-delimited JSON.

Paste below or choose a file
Sample format and supported fields

Each sample uses method, path or url, status, optional request.body, request.headers, request.query, response.body and response.headers. A browser HAR export is also accepted. Missing HTTP status is reported as unverified, not silently treated as 200. Captured bodies must be valid JSON values for JSON-schema checks.

API samples may contain secrets. Review before exporting reports. This editor never sends them anywhere.

COMPATIBILITY REPORT

Drift findings

Not analyzed
Potential breaking—Contract violations / risky changes
Warnings—Coverage or potential risk
Informational—Unspecified / newly added
Samples / endpoints—Awaiting analysis

Observed operation coverage appears here after analysis.

This is a local static analysis, not a live API tester. Evidence from observed samples cannot guarantee forward or backward compatibility.

0 shown
⌁

Your drift report starts here

Use the demo to see how mismatched types, missing properties and undocumented statuses are surfaced.

03

Share your findings

Export the analysis for pull requests, QA tickets or CI follow-up.

Reports use operation templates rather than observed URL IDs; unmatched URLs are withheld. Reports do not contain raw request or response bodies. Review potentially sensitive field names before sharing.

Interpretation matters

Potential breaking means a violation was observed or a change is likely incompatible. Warnings require review. An empty report only means no supported checks found issues in the supplied evidence.

BUILT FOR API ENGINEERING

Find problems before your clients do.

01 / Define

Load the contract

Start with OpenAPI 3.0 or 3.1 JSON, or supported YAML. Local component references are resolved without network access.

02 / Observe

Compare real traffic

Import request/response samples or HAR captures. Detect nested field mismatches, required-property gaps, status changes, and additional fields.

03 / Review

Prioritize fixes

Filter by risk and export JSON or CSV reports. Or compare two versions of an OpenAPI contract before release.

FAQ

Does the tool call my API?

No. There is no endpoint probing, URL fetching, secret storage, backend or cloud processing. It works only on files and text you provide.

Does it fully implement JSON Schema 2020-12?

No. It performs practical checks for common OpenAPI constraints and internal references. Complex schema dialect features, discriminators, conditional keywords, external references and arbitrary YAML features are not fully supported.

Does a green report mean an API is backward compatible?

No. Samples are evidence, not exhaustive proof. Dynamic behavior, authentication, semantics, client assumptions and untested schema branches can still be incompatible.

What format should my samples use?

Use an array of objects with method, path, status and optional request/response bodies, NDJSON records or HAR data. Review or redact credentials and personal information before saving or sharing.

Compare API contracts with captured samples

Import an OpenAPI JSON document or the supported conservative YAML subset, then compare it with supplied JSON, NDJSON or HAR request/response samples—or compare two contract versions. Review potential drift and operation coverage before exporting findings.

Example workflow

  1. Load a reference contract and a small set of captured samples, or add a candidate contract for comparison.
  2. Review operation matches, schema-subset findings and coverage; check each potential risk against the full contract and API behavior.
  3. Export findings JSON/CSV and operation-coverage CSV, keeping the contract and captures available for review.

Authored example: Create a fictional response contract that requires a currency field, then compare a captured response that omits it. Treat the output as a candidate mismatch and verify it against the full schema and endpoint specification.

Limits and privacy: The tool does not call live endpoints or fully implement OpenAPI/JSON Schema. External references and advanced YAML/schema semantics are unsupported. A missing status is not assumed to be 200, and unobserved operations are not proven unused. Exports omit raw response bodies but can reveal contract details; review them before sharing.

Related tools