Test malformed JSON separately from valid JSON that violates an API’s schema. Start with the endpoint’s contract, establish a valid control request, then vary one input condition at a time and check the full observable response: status, headers, media type, body shape, error detail, and service behavior afterward. HTTP standards guide protocol-level expectations, but the API contract determines application-specific validation rules.
Start with the API contract
Use the endpoint’s OpenAPI document or equivalent documentation to turn requirements into test cases. OpenAPI is an interface description for HTTP APIs that can support documentation, code generation, and testing tools; the current official specification page identifies version 3.2.1, dated 10 September 2026. Deployed APIs may describe an older version, so test against the version the service actually declares. OpenAPI Specification
As an Amazon Associate I earn from qualifying purchases.
For the operation under test, record:
- HTTP method and path, authentication requirements, and required headers.
- Accepted request media types and the expected success status, response headers, and body shape.
- Required properties, types, nullability, enum values, formats, numeric and string constraints, array rules, and documented size limits.
- Documented error responses and their required body fields.
OpenAPI property names are case-sensitive. Do not assume an omitted property, a misspelled key, or a value of null is treated the way another API treats it.
Recommended Free Tools
Establish a valid control request
Before sending negative cases, submit an ordinary valid request in a controlled environment. Save the request and record the expected success status, response headers, and body shape. This gives you a baseline: when a later request fails, you can distinguish a validation result from a broken setup, expired authentication, or an endpoint that was already unavailable.
#1 Best Overall
Separate malformed JSON from invalid request data
These are different failure classes. Malformed JSON cannot be parsed as JSON; valid JSON can still have the wrong shape or violate the endpoint’s rules. Test the two classes separately so the result tells you which layer rejected the request.
Malformed JSON syntax
Try one syntax defect per request, such as a truncated object, a missing comma, an invalid token, or invalid escaping. RFC 7231 describes 400 Bad Request as applying when a server cannot or will not process a request because of a perceived client error, including malformed request syntax. Treat 400 as a protocol-grounded expectation, then verify the API’s documented response behavior. RFC 7231
Parseable JSON that violates the schema
Send syntactically valid JSON with one schema violation at a time: omit a required property, use a string where a number is expected, provide a disallowed null, choose an unknown enum value, or supply a value outside a documented constraint. The API contract—not a general HTTP rule—determines the expected application-level validation response.
Build a repeatable edge-case matrix
Adapt this matrix to the endpoint. For each test, preserve the valid control and change one relevant condition so failures are diagnosable.
Rank #3
| Dimension | Example variations | What to assert |
|---|---|---|
| JSON syntax | Truncated document, missing delimiter, invalid token, invalid escape | Rejection behavior, protocol status, and a safe response |
| Top-level value | Object, array, string, number, boolean, null |
Whether the submitted shape is allowed by the endpoint schema |
| Required properties | Omit each required key, then test combinations | Contract-consistent validation response |
| Types and nullability | String instead of number; null; integer versus decimal; boolean versus string |
Rejection or documented coercion behavior |
| Boundaries | Minimum, maximum, just below, just above, empty, very long | Correct enforcement of documented boundaries without unexpected failure |
| Enums and formats | Unknown enum; malformed date, URI, or email where formats apply | Documented validation response; do not presume format checking unless specified |
| Nested objects and arrays | Missing nested object; invalid member; empty or oversized array | Correct diagnosis of the failing path or member and safe handling |
| Unknown keys | Extra property, misspelled key, case variation | Behavior documented by the API; OpenAPI field names are case-sensitive |
| Request headers | Missing, correct, or unsupported Content-Type; relevant Accept variations |
Documented status and response media type |
| Payload size | At the documented limit and just above it | Limit enforcement and the applicable HTTP response behavior |
| Error response | Status, Content-Type, required fields, extensions |
Stable, machine-readable shape and useful error information |
Test request metadata and payload limits
Content type and response negotiation
Send requests with the documented Content-Type, without it, and with an unsupported value. Where relevant, vary Accept and content encoding too. RFC 7231 defines 415 Unsupported Media Type for an unsupported payload format, but the accepted types and complete response behavior are endpoint-specific.
Size boundaries
In a controlled environment, test the documented maximum and a request just above it. RFC 7231 defines 413 Payload Too Large for a payload the server is unwilling or unable to process. Keep boundary tests bounded; do not send unbounded payloads to production.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Assert the error response, not just the status
Check status and response media type first. Parse the body as JSON only when its content type indicates JSON, then validate the documented response shape and fields. An error status alone does not show whether callers can reliably understand or handle the failure.
Problem Details responses
RFC 9457 defines the application/problem+json format for HTTP problem details. When an API documents this format, inspect type, title, status, detail, and instance where provided, as well as documented extension members. The RFC’s example uses an errors array whose entries include a human-readable detail and a JSON Pointer pointer, which can identify the input location associated with a validation error. RFC 9457
Error messages should explain the interface problem without exposing implementation internals. For multiple problems of different types, RFC 9457 recommends representing the most relevant or urgent problem rather than inventing a generic batch format that does not map well to HTTP semantics.
Check service behavior after rejection
After an invalid request, send a valid request or otherwise confirm that the service remains responsive. For operations expected to be atomic, check that a rejected request did not partially change state. These are test-design checks; the cited HTTP and Problem Details standards do not prescribe a particular transaction model.
Keep the test suite tied to a version
Record the API revision and the OpenAPI version used to create the tests. Validators and API versions may differ in how they handle extra fields, null, or format validation. Keep expected statuses, headers, and response bodies linked to the contract version so a specification change prompts a deliberate test update rather than a misleading pass or failure.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
