Test API Contracts: Format JSON → Diff Responses → Validate Regex
Verify API contracts haven't broken: format response JSON for readability, diff expected vs actual responses, and validate field formats with regex. Catch breaking changes before users do.
The Problem
You're integrating with a third-party API and after their latest update, your client is broken. Or you made a backend change and need to verify the response format hasn't changed. Either way, you need to compare JSON responses, validate field formats, and confirm the contract is intact.
Why This Matters
API contract testing prevents integration failures from becoming production incidents. Manually comparing JSON responses is error-prone — the Diff Checker makes structural changes immediately visible. Regex validation confirms individual field formats conform to the contract spec.
Step-by-Step Instructions
Format both JSON responses for comparison
Copy the expected JSON response (from documentation or the last known-good response) and the actual response into the JSON Formatter separately to pretty-print both. Consistent indentation is essential for accurate diffing.
Diff expected vs actual response
Paste the expected response in the left panel and the actual response in the right panel of the Diff Checker. Any field additions, removals, renames, or type changes appear highlighted — these are breaking changes.
Validate field formats with regex
For critical fields like IDs, timestamps, and emails, use the Regex Tester to verify the format against your contract spec. If the API contract says id is a UUID, test the actual values with [0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}.
Try It Now — Diff Checker
Open full page →All processing happens in your browser — no data is sent to any server.
Before & After Example
// Expected response (v1)
{"id":"550e8400","user_id":123,"status":"active","created_at":1709800000}
// Actual response (v2)
{"id":"550e8400","userId":123,"status":"enabled","createdAt":"2026-03-07"}
# Differences:
# user_id → userId (renamed!)
# status value changed: "active" → "enabled"
# created_at format changed: Unix → ISO 8601
Fields changed (breaking): - user_id → userId (key renamed) - status: 'active' → 'enabled' (value changed) - created_at → createdAt (key renamed) - created_at format: int → string (type changed) Impact: - All clients using user_id will break - All status checks for 'active' will fail - Date parsing code needs to handle ISO format
Frequently Asked Questions
What is API contract testing vs integration testing?
Contract testing verifies the shape, format, and semantics of API responses independently of business logic. Integration testing verifies end-to-end behavior. Tools like Pact automate contract testing in CI/CD. This manual workflow is for ad-hoc verification during development.
How do I detect API breaking changes automatically?
Use Spectral or Optic for OpenAPI spec linting. Integrate Pact for consumer-driven contract tests in CI. For GraphQL, use Apollo Studio schema checks. For REST without OpenAPI, snapshot test your response fixtures and fail CI on unexpected diffs.
What counts as a breaking change in a REST API?
Breaking: removing a field, renaming a field, changing a field type, changing a required field to optional (sometimes), changing status code semantics. Non-breaking: adding a new optional field, adding a new endpoint, adding new enum values (if clients handle unknown values).
Related Workflows
Try all 3 tools in this workflow
Each tool is free, runs in your browser, and requires no signup.