Parity Bench· differential API testing
For drop-in API replacements

Run both systems.
See every difference.

Parity Bench fires the same request at v1 and v2, then compares the responses key-by-key and byte-by-byte — values, shapes, row order, and latency — so devs and testers can prove a replacement is truly drop-in before anything cuts over.

Open the bench →
31 endpoints · 300+ sweep scenarios
v1POST /reports/cell-drilldown-deal-wise200412 ms
  "id": "January-2025",
  "fundedAmount": 1835500,
  "totalDeals": 89,
  "factorRate": 1.43,
  "totalOutstandingFees": 660466
v2POST /reports/cell-drilldown-deal-wise20038 ms warm
  "id": "January-2025",
  "fundedAmount": 1835500,
  "totalDeals": 89,
  "factorRate": 1.51,
  "totalOutstandingFees": 660466
1 value diff$.data.details[0].factorRaterow order OK10.8× warm

One request, two systems

Point it at the legacy API and its replacement. Each side gets its own base URL and its own auth — different login systems are the normal case, not a problem.

A diff engine that doesn't cry wolf

Canonicalizes what should legitimately differ — float noise, datetime formatting, null vs missing, per-request random ids — then flags everything else, including row order.

Sweeps, not spot checks

Every dimension × key metric per endpoint, generated from each endpoint's real request contract. Invalid payloads are rejected before they can produce a false diff.

Latency as evidence

Cold vs warm, connect/TTFB/download phases, and honestly-labelled speedups — so the replacement's performance story holds up in review.

built for the Kesef v1 → v2 reports migration — works for any pair of endpoints that should agree