About this tool
Negative testing an endpoint means sending the same body many times with exactly one thing wrong. Writing those variants by hand is slow and it is easy to miss one. Paste a JSON Schema and this tool walks its type, required, enum, minimum/maximum, minLength/maxLength, format and items keywords to build a valid payload, then derives one variant per rule: each required field removed, each field with the wrong type or null, strings one character outside their length limits, numbers one step outside their range, an invalid enum value, malformed emails and dates, an extra unknown property and an empty object. Paste an example body instead and every present field is treated as required, with formats inferred from the values. $ref, allOf/anyOf/oneOf and pattern are not resolved, so review those fields yourself.
How to use it
- Paste a JSON Schema or a real request body, or load one of the samples. Auto-detect decides which it is; override it with the toggle if needed.
- Copy the valid payload for your happy-path test.
- Filter the negative variants by category, expand any variant to inspect or copy it, or export them all as a JSON array of {name, payload} to drive a data-driven test.
API Payload Generator FAQ
What is an API payload?
An API payload is the data carried in the body of a request or response, usually JSON for REST APIs. For example, a POST /users request might send {"name": "Asha", "email": "asha@example.com"}. The method, URL and headers describe the request; the payload is its content. In testing, request payloads are your inputs, and response payloads are what you assert against, so both need to match the API contract.
How do I generate JSON payloads for API testing?
Start from the API contract. Paste its JSON Schema, or a real request body, into this generator and it builds a valid payload plus one negative variant per rule: a missing required field, a wrong type, a value outside a range, an invalid enum and more. Export them as JSON and loop over them in your tests. For realistic values in bulk, use the test data generator; for ready-made examples, see sample JSON payloads.
What should a POST request payload contain?
Exactly what the API contract requires to create the resource: every required field with the correct type and format, plus any optional fields relevant to the scenario. It should not contain server-generated fields such as id or createdAt unless the API expects them. Send it with a Content-Type: application/json header. A successful create usually returns 201 Created with the new resource or a Location header; an invalid payload should return 400 or 422 with a clear error.
How do I create negative test payloads?
Take one valid payload and break exactly one thing per test, so a failure points to a single rule. Typical variants: remove each required field, send the wrong type or null, exceed length or numeric limits by one, use an invalid enum value or a malformed email, add an unknown property, and send an empty object. Each should be rejected with a 4xx status and a helpful error, never a 500. This generator derives those variants from a schema automatically.
What are common JSON payload formats?
Most REST APIs use a JSON object, often with nested objects such as a user with an address. Other common shapes are arrays of objects for bulk operations; envelopes that wrap results in data and meta fields; GraphQL requests with query and variables; and RFC 9457 problem details for errors, with type, title, status and detail. Browse realistic request and response bodies in the sample JSON payloads library.
Can I generate random test data for API testing?
Yes. Randomised data finds bugs that hand-picked values miss, but it should be reproducible. The test data generator creates realistic names, emails, addresses, UUIDs, numbers and dates with Faker, and a fixed seed returns the same data every time, so a failing test can be replayed. Faker libraries for JavaScript and Python, or Datafaker for Java, do the same inside your tests. For edge-case strings, use the test string generator.
What status code should the negative payloads produce?
Usually 400 Bad Request or 422 Unprocessable Content, with an error body naming the field. Whatever the API documents, it should be consistent across endpoints, and none of these variants should ever produce a 500.
How do I use the exported JSON in a test?
Load the array and loop over it: in Playwright, for (const { name, payload } of variants) test(name, ...); in JUnit 5 use a @MethodSource or @ParameterizedTest with a JSON source; in Postman, use it as a collection runner data file.
Why is “Null value” not generated for some fields?
If the schema allows null for a field (type: ["string", "null"] or null in its enum), sending null is valid, so it is not a negative case.