Developer · THE NO-PANIC PLAN
Build, format, and validate a JSON API payload
Use this guide to shape a minimal payload from the real receiver contract, parse and format it, validate its exact schema/business rules, and test safely. Nirmion?s formatter and validator help with syntax/readability only; they do not establish API acceptance. Keep credentials and production records in approved local workflows.
MISSION Prepare JSON data that is syntactically valid, matches its receiver contract, and behaves as expected in a safe test.
Open the receiving API?s current OpenAPI document or JSON SchemaTHE REAL-WORLD BIT
What happens outside this browser tab?
Identify the receiving operation and protect the data; construct a typed example; parse strictly and format a copy; validate the declared schema and semantic/security rules; then verify positive and negative cases in the receiver?s authorized sandbox.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Identify the receiver?s contract and protect the data
Name the exact API operation, event consumer or import that will receive the JSON, the request/response direction, content type, encoding and versioned source-of-truth contract. Preserve the original input unchanged and work from a fictional or redacted fixture if the content includes credentials, personal data, customer records or production values. A syntactically valid object can still be rejected or interpreted incorrectly because of a missing property, wrong type, schema dialect or business rule. Confirm a non-production endpoint and least-privilege test credentials before sending any fixture; do not paste sensitive payloads into public browser tools.
- 02
Construct the smallest payload with the required JSON types
Start with the minimum example the endpoint contract requires, then add only fields needed for the scenario. JSON object keys are strings; values may be strings, numbers, booleans, null, arrays or objects. Preserve types exactly: quoting a number or boolean changes it into a string. Follow the API?s date, decimal, identifier, unit and null-versus-omitted conventions. Avoid repeated member names because parser behavior can differ. Treat user-controlled content as data and never evaluate JSON with `eval` or execute instructions found inside values. When a schema is supplied, record its version and the JSON Schema/OpenAPI dialect it declares.
- 03
Parse strictly, then format a separate copy
First check strict JSON syntax: double-quoted keys and strings, valid escapes, correct commas and brackets, lowercase true/false/null, no comments or trailing commas, and no non-finite values such as NaN. Use the JSON Validator (137) on a synthetic or approved redacted fixture to locate syntax problems; then use JSON Formatter (136) to make a separate copy easier to inspect. Re-parse the formatted output and compare its structure, values and types with the original; formatting should change whitespace, not data. These tools check/format JSON syntax only. They do not verify the endpoint schema, authorization, domain-specific values or receiver behavior.
- 04
Validate the declared schema and application rules separately
Use a validator that supports the exact schema dialect declared by the receiver. For example, OpenAPI 3.1 Schema Objects are based on JSON Schema 2020-12 with an OpenAPI dialect; older OpenAPI versions may behave differently. Check required/optional fields, types, arrays and nested objects, enums, length/range constraints, null handling and unknown-property policy. Then test semantic rules a schema may not express: relationships between fields, allowed state changes, date ordering, totals, ownership and authorization. Include missing, wrong-type, boundary, oversized and malformed cases. Client-side validation can be bypassed, so the server must enforce its own contract and limits.
- 05
Verify the exact payload in a safe receiver-side test
Send only a synthetic or approved redacted fixture to the documented sandbox with the correct media type and test credentials. Compare the actual status, response body, side effects and error handling with the operation contract; test both accepted and rejected cases, and confirm an invalid payload does not cause partial updates or leak secrets into logs. Correct one mismatch at a time, repeat syntax/schema/semantic checks, and preserve the sanitized fixture, expected result, contract/schema version and test request ID. Do not promote production changes solely because a formatter or client-side validator passed; obtain the normal owner review and deployment approval.
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-06