How to Check Missing and Null Fields in a JSON Response

A JSON response that omits delivery_note is different from one that includes "delivery_note": null. Optional describes whether a field may be absent. Nullable describes whether its value may be null when present. Check both rules before replacing values or deciding that a response matches an API contract.

The examples below use an invented parcel response. They demonstrate a manual contract review, with the JSON Formatter and Validator providing readable working copies.

Write down the presence and null rules separately

Find the documentation or schema for the exact endpoint, response status and API version you are using. For this fictional response, the agreement is:

A required nullable field is therefore possible: tracking_code must appear, but its value can be null. An optional nonnullable field is also possible: delivery_note may disappear, but must be a string if supplied. Do not infer either rule from the field name.

Format three responses without changing their values

1. Keep an untouched copy of each response.
2. Paste one example into Paste your JSON.
3. Choose 2 spaces under Indent. Leave Minify and Sort keys alphabetically unchecked.
4. Select Format JSON, then check field presence and values against the table.

All three examples parse successfully. MDN documents JSON.parse as converting valid JSON text into values. Parsing alone does not supply the endpoint rules in our table. The formatter does not run a JSON Schema validator.

1. An optional field is omitted

{"order_ref":"DEMO-42","tracking_code":null}

The formatted result is:

{
  "order_ref": "DEMO-42",
  "tracking_code": null
}

This satisfies the fictional field rules. The optional note is absent, and the required tracking field is present with an allowed null value.

2. The optional field is present with null

{"order_ref":"DEMO-42","tracking_code":null,"delivery_note":null}

This still produces the formatter success message. However, delivery_note now exists with a disallowed value. Its optional status does not make null acceptable.

3. The fields contain permitted strings

{"order_ref":"DEMO-42","tracking_code":"TRK-8","delivery_note":"Leave at reception"}

This also satisfies the fictional field rules. Do not add quotation marks around null as a general repair: "null" is a string containing four letters, not the null value. Likewise, an empty string is another distinct value; whether it is acceptable depends on the contract.

Check a missing required field as a separate failure

Now remove tracking_code entirely:

{"order_ref":"DEMO-42"}

The text remains valid JSON, but it fails the presence rule. Allowing null never authorized omission. The official JSON Schema object reference explains that properties describes fields, while required specifies which must appear. It also distinguishes a present null from an absent property.

An illustrative schema for this checklist is:

{
  "type": "object",
  "properties": {
    "order_ref": {"type": "string"},
    "tracking_code": {"type": ["string", "null"]},
    "delivery_note": {"type": "string"}
  },
  "required": ["order_ref", "tracking_code"]
}

The JSON Schema type reference describes allowing multiple types with an array. This example does not restrict extra fields or string lengths; use the complete real schema for those decisions.

Report the mismatch before adding a fallback

Record the field path, whether it was missing or present, its actual value, and the documented rule. For example: delivery_note: present null; expected string when present. This gives the producer a specific issue to reproduce.

Do not silently convert absent fields to null, invent a tracking code, or insert empty strings to hide a contract mismatch. Resolve the expected behavior with the integration owner and test the agreed response. For punctuation failures, use the JSON syntax repair guide before performing this presence review.