flashman
← All guides

JSON Schema property dependencies with dependent keywords

Model conditional object requirements with dependentRequired and dependentSchemas by pinning the dialect, defining trigger presence, composing rules, and testing boundaries.

2026-09-21 · 8 min read

  • json-schema
  • validation
  • object-modeling

Object properties often travel in groups: a credit-card number may require a billing address, or the presence of one integration setting may activate a richer configuration schema. JSON Schema provides separate keywords for peer-property requirements and schema-based dependencies.

dependentRequired maps a trigger property to names that must also exist. dependentSchemas maps a trigger property to a schema evaluated against the whole containing object. Both depend on property presence, not whether the trigger value is true, nonempty, or non-null.

Choose the smallest suitable keyword

Use dependentRequired when the complete consequence is that named peers must exist. Use dependentSchemas when the trigger activates types, value constraints, additional required names, composition, or restrictions elsewhere in the same object.

  • Keep simple presence rules declarative.
  • Avoid replacing value conditionals with presence dependencies.
  • Place each rule at the object level it governs.
  • Use references to name reusable complex schemas.

Pin and migrate the dialect

Declare $schema and verify that every validator, editor, code generator, and documentation pipeline supports the chosen dialect. Older schemas may use dependencies with either an array or schema value; migrate intentionally rather than renaming without conformance tests.

Configure production validators to surface unknown required vocabulary or unsupported keywords. Silent keyword ignoring can turn a required business invariant into documentation only.

Coordinate composition and object closure

A dependent schema evaluates the complete object and can combine with allOf, anyOf, if and then, references, and unevaluatedProperties. Track successful evaluations under the selected dialect before closing an object to properties introduced by another branch.

Keep trigger names stable across API naming conventions. Case conversion, aliases, and deserialization before validation can otherwise make the validator and application operate on different objects.

Maintain a dependency fixture matrix

Use Flashman's JSON formatter for schemas and instances, diff for minimal fixture changes, case converter for property names, regex tester for value constraints, and YAML converter for configuration examples.

Cover absent triggers, null and false trigger values, each missing peer, all peers, nested objects, multiple simultaneous triggers, unexpected properties, composed schemas, unresolved references, older syntax, and validator upgrades.

Try these tools