Find missing fields and incorrect types

Tools to use

• Open this tool: JSON Schema validator

Start with one valid document and schema

{"name":"Notebook","count":2,"status":"draft"}

{
  "type": "object",
  "required": ["name", "count"],
  "properties": {
    "name": { "type": "string" },
    "count": { "type": "integer", "minimum": 0 },
    "status": { "enum": ["draft", "published"] }
  }
}

This pair passes: name and count exist, name is a string, count is a nonnegative integer, and status is allowed. Establishing a passing baseline separates mistakes in the document from mistakes in the schema. Keep the schema fixed and change one data condition at a time.

A property definition alone does not make it required

{"name":"Notebook","status":"draft"}

Omitting count fails because required lists it. Omitting status alone passes this schema. Properties describes conditions when a field exists; required lists fields that must exist. Check this distinction when a defined field unexpectedly disappears without an error.

Required does not mean nonempty. An empty name still passes these particular rules because it is a string. Rejecting empty strings needs a separate condition. Passing this example does not guarantee a meaningful business name.

2, "2", and null are different values

{"name":"Notebook","count":"2","status":"draft"}

Quoted 2 is a string and fails integer validation; the validator does not coerce it merely because it looks numeric. Null also fails the integer rule even though the property exists. Keep absence, empty string, null, and numeric zero distinct in the data contract.

CSV conversions often expose this issue: a cell that looks like 2 need not become a JSON integer. An ID with leading zeroes may need to remain a string. Do not convert every numeric-looking cell just to satisfy a schema; establish each field's meaning.

The right type can still contain a disallowed value

{"name":"Notebook","count":-1,"status":"archived"}

Minus one is an integer but violates minimum:0; archived is absent from enum. Types alone do not express allowed business values. Restoring count to 0 and status to draft resolves these two problems. Revalidate after each repair instead of assuming one change fixes every error.

Adding archived to enum may make validation pass without making the recipient capable of handling it. Determine whether the data is wrong or the agreed specification changed; do not weaken the contract merely to remove an error. Producers and consumers need matching schema versions.

This example does not forbid unknown properties

Adding an extra property is not forbidden by this schema: properties is not an exclusive allowlist. SheepDev rejects unsupported keywords such as additionalProperties. If you need a complete contract, also validate with an implementation supporting its dialect and keywords.

Schemas using $schema, $ref, or $dynamicRef are rejected and no external schema is fetched. A copied official example may therefore fail here. Removing unsupported parts and passing the remainder is not validation against the original whole schema. Record partial experiments separately from full contract checks.

Record what passed and what remains unchecked

On success, record which required fields, types, enum values, and bounds were checked. Authentication, existence of IDs, stock, and cross-field business rules are outside this example. 'Schema passed' does not mean 'the API must accept it'; this is one preflight step.

Keep tests for missing fields, numeric strings, null, negatives, and unknown states alongside the valid example. Checking both acceptance and rejection catches unintended relaxation when the schema changes. Use error paths to decide whether the document or the contract needs correction.

Why can schema-valid data still fail an order?

A quantity may be an integer of at least one and a product ID a string, yet the product could be unavailable or out of stock. Structural validation and checks against business data are different layers. This tool makes no database or service lookup, so success does not establish that an ID exists or an order can be fulfilled. State which layer passed.

Keep negative fixtures for missing required fields, stringified numbers and values outside an enum. After a schema edit, a formerly rejected example passing should be an intentional relaxation. Removing required merely to silence an error may remove a check rather than fix the data. Also verify that keywords are supported by this implementation; unsupported rules cannot count as completed validation.

Sources

• JSON Schema — Object properties and required fields (Opens in a new tab)

Tools to use

• JSON Schema validator