Let me tell you three real stories. These are the kind of bugs that make senior QA engineers lose sleep.
A banking app shows the user's account balance on the dashboard. The API returns { "accountId": "123", "balance": 50000, "currency": "INR" }. One day, the backend team deploys a change. They rename "balance" to "availableBalance." The frontend still reads "balance" — gets undefined. The dashboard shows "₹undefined." Nobody caught it because the tests only checked status code 200.
An e-commerce API returns product price as a number: { "price": 999.99 }. After a backend refactor, it starts returning price as a string: { "price": "999.99" }. The mobile app does price * quantity. With a string, JavaScript gives "999.99999.99999.99" instead of 2999.97. The cart shows garbage. The tests checked pm.expect(json.price).to.exist — it existed. It was just the wrong type.
An insurance portal API returns user profile data. The "phone" field is always a string: "9876543210." One day, a user signs up without entering a phone number. The API returns "phone": null instead of "phone": "". The frontend tries phone.substring(0, 3) — crashes with "Cannot read property substring of null." Production is down for 2 hours.
All three bugs would have been caught by a JSON Schema that enforced field names, types, and non-null constraints. These are not hypothetical — these are patterns that repeat across every company.
| Problem | What Happened | Schema Rule That Catches It |
|---|---|---|
| Field renamed | "balance" became "availableBalance" | "required": ["balance"] — fails if field missing |
| Type changed | Number became string | "type": "number" — fails if string received |
| Null value | String field returned null | "type": "string" (without nullable) — fails on null |
| Extra field added | API added "internalId" by accident | "additionalProperties": false — fails on extra fields |
| Field removed | "currency" field disappeared | "required": ["currency"] — fails if absent |
| Array became object | [{...}] became {...} | "type": "array" — fails if object received |
| Nested object changed | address.zipcode became address.zip | Nested schema with required fields catches it |
Key Point: Schema validation is not about checking values. It is about checking structure. "Is the balance 50000?" is a value check. "Does the balance field exist and is it a number?" is a schema check. Both are needed. Schema catches the structural bugs that value checks miss.
Q: Can you give a real example where schema validation would have prevented a production bug?
A: Yes. Imagine an API that returns user profiles with a "phone" field as a string. If a backend change makes it return null for users without a phone number, the frontend code that calls phone.substring() crashes. A schema with "type": "string" (without allowing null) would catch this in the test pipeline before it reaches production. Similarly, if a field is renamed or its type changes, the required and type rules in the schema would fail the test immediately.
Key Point: Schema validation catches structural bugs that value-based assertions miss — renamed fields, type changes, null surprises, and unexpected fields.