Developer · THE NO-PANIC PLAN
Validate an API JSON payload against its contract
A request can be valid JSON and still violate the API contract. This workflow separates syntax checks from schema validation and endpoint behavior, and keeps credentials and real user data out of examples. Nirmion JSON Validator checks JSON syntax only; use a validator that supports the API's actual OpenAPI/JSON Schema dialect for contract rules, then test through an authorized non-production endpoint.
MISSION Check that a sanitized API request is valid JSON, conforms to the endpoint's versioned schema and behaves as documented in an authorized test environment.
Validate a JSON requestTHE REAL-WORLD BIT
What happens outside this browser tab?
Get the deployed endpoint contract; create a synthetic and sanitized sample; validate JSON syntax; validate the sample against the matching schema dialect; test the endpoint safely; and keep a reproducible record with secrets removed.
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
Get the current contract for the exact endpoint
Identify the API owner, environment, HTTP method, route and operation version you are authorized to test. Obtain the current OpenAPI description or JSON Schema from the service owner and confirm the schema dialect, request media type, required fields, authentication method, size limits and expected success/error responses. Do not infer the contract from one successful example or a stale client. OpenAPI describes operations and request bodies so clients can understand an API, while JSON Schema defines structural validation vocabularies; the service's deployed contract determines which rules apply. Record the version or commit of the contract and use a non-production environment unless an owner has explicitly approved another safe test plan. (Sources 2, 3)
- 02
Sanitize a representative payload and validate JSON syntax
Create the smallest sample that represents the intended request and remove real names, account identifiers, tokens, passwords, keys, session cookies and confidential business values before pasting it into any utility. Keep types and field shapes representative while replacing sensitive values with clearly synthetic examples. Nirmion JSON Validator (tool 137) checks whether one input is syntactically valid JSON and reports its root type, depth and structural counts. RFC 8259 defines JSON grammar, but a syntactically valid document can still omit required fields or violate the endpoint schema. Do not send production credentials to this parser; review its current page and limits before using any real payload. (Source 1)
- 03
Validate the payload against the versioned schema
Run the sanitized sample through a validator that supports the schema dialect in the endpoint's current contract. Check required properties, data types, allowed enum values, formats, array item rules, numeric bounds, string constraints, nullability and whether extra properties are permitted. Inspect the reported JSON path for each failure and distinguish a schema error from business rules or authorization checks that the schema cannot prove. OWASP recommends validating type, range, format and size and rejecting unexpected input; OpenAPI and JSON Schema describe the relevant contract structure. Nirmion JSON Validator does not validate an API schema, and this workflow does not claim that it does. If the contract is ambiguous or the schema is missing, ask the API owner to clarify instead of guessing. (Sources 2, 3, 4)
- 04
Exercise the endpoint safely in an approved test environment
After schema checks pass, send the sample only to the authorized test endpoint using the documented HTTP method, URL, Content-Type, authentication flow and required headers. Use a short-lived test credential from the approved secret store; do not paste it into this page or commit it in a request file. Confirm the server response matches the contract, including status code, response media type, required response fields and documented validation errors. OWASP recommends matching request content types to the API's supported media types and bounding request sizes. A local schema pass cannot establish authorization, server-side business behavior, persistence or production readiness. Avoid load testing, destructive operations and real customer data unless a separately approved test plan covers them. (Sources 3, 4)
- 05
Record the result and rerun after contract changes
Save a reproducible, sanitized record containing the API and schema versions, route and method, test environment, synthetic payload, validator/dialect, expected and actual result, response status and any issue reference. Keep tokens, personal information and private response fields out of logs and shared tickets. If the contract changes, regenerate or review the sample and rerun syntax, schema and endpoint checks against the updated version. Treat failures as evidence to investigate with the API owner, not as an automatic defect in the service or client. OWASP recommends bounded input validation and secure parsing; the record should preserve only the data needed to reproduce the check. Remove temporary test data and revoke short-lived credentials according to the team's normal process. (Source 4)
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-07