OpenAPI Negative Test Generator
Paste an OpenAPI 3.0 or 3.1 description as YAML or JSON. For each operation the generator lists the requests the description says must be refused: required fields left out, wrong types, values one step past minLength, maxLength, minimum, maximum and the exclusive bounds, enum and pattern violations, invalid formats, undeclared properties when additionalProperties is false, nulls the schema does not allow, and missing, invalid or under-scoped credentials with the expected 401 or 403. Bounds and nulls follow the document's own version: boolean exclusiveMinimum and nullable in 3.0, numeric exclusiveMinimum and type arrays with null in 3.1, and 3.0 spellings left in a 3.1 document are flagged. Export the checklist as Markdown or as Playwright request tests. Local $refs are resolved with a cycle guard, remote ones are reported and never fetched, and everything runs in your browser.
Negative cases from OpenAPI
OpenAPI 3.0 · 3.1 · Client-Side Only
Read in this browser tab. Cases follow the OpenAPI 3.0 or 3.1 rules, whichever the document declares, and JSON Schema 2020-12 for 3.1. Nothing is uploaded, and remote $ref URLs are reported, never fetched.
Rules checked against OpenAPI 3.0.3, 3.0.4 and 3.1.2 and JSON Schema 2020-12 on .
Orders API 2.4.0
- Rules
- OpenAPI 3.1
- Operations
- 3
- Negative cases
- 38
- Spec problems
- 3
POST /orderscreateOrder
30 casesPlace an order
Error: exclusiveMinimum: true is the 3.0 spelling. In 3.1 (JSON Schema 2020-12) it "MUST be a number"; a strict validator refuses this schema and a lenient one ignores the keyword, which leaves minimum: 0 inclusive. Write exclusiveMinimum: 0 and drop minimum.
#/paths/~1orders/post/requestBody/content/application~1json/schema/properties/unitPrice
Warning: nullable is not a keyword in OpenAPI 3.1, so it does nothing and null is rejected. Write type: ["string", "null"] instead.
#/paths/~1orders/post/requestBody/content/application~1json/schema/properties/giftMessage
GET /orders/{orderId}getOrder
4 casesWarning: This operation has invalid inputs to test but documents no 400, 422 or 4XX response, so the cases can only expect "some 4xx".
#/paths/~1orders~1{orderId}/get
DELETE /orders/{orderId}cancelOrder
4 casesFrequently Asked Questions(click to expand)
Why do the cases change when I edit only the openapi line?
Because the keywords change meaning. In 3.0, exclusiveMinimum: true makes minimum exclusive and nullable: true allows null. In 3.1 the Schema Object is JSON Schema 2020-12: exclusiveMinimum must be a number, and null is allowed only by a type array such as [string, "null"]. A 3.0 description relabelled 3.1 keeps the old spellings, and the generator flags each one.
Why are format cases marked as depending on the validator?
Both specifications treat format as an annotation by default, so an invalid email is only rejected if the server's validator is configured to check formats. A failing format test tells you which setup you have.
What does it do with $ref?
References inside the document (#/components/...) are followed, and a schema that refers back to itself stops at that level instead of looping. A reference to another file or URL is listed as a warning and never fetched, so paste the referenced schema into the same document to get its cases.
Why does my status-code test pass for the wrong reason?
A coercing validator can turn 12345 into "12345" and then reject it by pattern instead of type. Assert where the error points, not only the status: the guide to designing negative API tests from a contract shows how, and API authorization testing goes past the 401 and 403 cases listed here.
I have a Postman collection or example payloads, not a spec.
Open the collection in the Postman Collection Viewer to see which requests it already sends. For a payload with no schema, the JSON to Schema Generator drafts one; review its required list and bounds before generating cases from it, because an inferred schema only knows the example it saw.