Quick answer: A 200 status only means the request was accepted and returned a response. It does not confirm the body matches the contract, so a wrong field, a bad type, or a missing value can break the spec while the status stays green. Assert the response fields and check them against the schema, and keep contract evidence separate from the status code so a 200 cannot mask drift.
Why status and contract are different checks
The HTTP status lives at the transport layer. It answers whether the call succeeded, was rejected, or hit an error. The contract lives at the schema layer and answers whether the response shape and values match what the spec declares. Those are independent questions, and a 200 says nothing about the second one.
A response can break the contract in several ways.
- A required field is missing from the body.
- A field returns the wrong type, such as a number where a string is declared.
- A value has a shape the schema does not allow.
- A later step consumes the field and fails because it is wrong.
How a 200 still breaks a flow
Inside a scenario, a bad body often surfaces at the step that tries to use it rather than at the step that returned it.
| Situation | Status | Contract result | Downstream effect |
|---|---|---|---|
| Missing required field | 200 | Schema violation | A later step reads an undefined value |
| Wrong field type | 200 | Type drift | Processing or assertion fails |
| Unexpected value shape | 200 | Contract break | The extracted variable is unusable |
| Correct body | 200 | Matches schema | The flow proceeds |
Per-step field assertions catch these cases at the response that produced them, instead of waiting for a later request to fail.
Assert against the spec, not just the code
Treat the declared spec version as the reference and check the response against it rather than against a lowest-common-denominator assumption.
- Assert the status to confirm the call was accepted.
- Assert the required fields are present.
- Check field types and shapes against the schema.
- Confirm any extracted variable matches the expected form.
- Let the next step consume the verified value.
Contract evidence is its own class, alongside static, dynamic, and model-only hypothesis evidence. The deterministic verdict fails on real drift, and a lack of verified evidence reads inconclusive rather than passing. The model cannot talk a schema violation into a pass.
Honest limits
A field assertion only covers the fields you check, so an unasserted part of the response carries no evidence. A passing run says the asserted fields and schema held, not that every possible value is valid. Keep the checks focused on the fields the flow and the contract depend on, and remember that static and contract signals are not guarantees about runtime behavior outside the run.
Scenarios stay outside the OpenAPI document with no x-scenarios keys and run against real connected requests. A mock returning fixed 200 answers cannot confirm the real backend conforms to the schema.
Powerduck keeps the contract checks and per-step assertions visible, so a 200 with a bad body is reported against the response rather than hidden behind a green status.
Frequently asked questions
Does a 200 mean the response matches the spec? No. It only means the call was accepted. A missing field or wrong type can break the contract while the status stays 200.
How do I catch a contract break behind a green status? Assert the response fields and check them against the schema, not just the status code, so type drift and missing fields are caught at that step.
What happens to a later step that consumes the bad field? It often fails when it reads the wrong or missing value, which is why asserting at the earlier response is more precise than debugging the downstream failure.
The bottom line
Never treat a 200 as a contract check. The status confirms the call was accepted, while the schema decides whether the body conforms, and a missing field or wrong type can break both the spec and a later step while the status stays green. Assert the fields against the declared spec, keep contract evidence separate, and remember that unchecked fields carry no evidence. A green status is a starting point, not proof that the response is valid. More in the API scenario testing guide.
Top comments (0)