Description

n8n-nodes-data-validator

This is an n8n community node that validates input data against a JSON Schema.

The node ships with a self-contained JSON Schema validator and has no runtime dependencies, which is what n8n Cloud requires of community nodes.

Use it to guard your workflows against malformed data — for example, validating incoming webhook payloads before passing them on to downstream services.

Installation
Operations
Usage
Compatibility
Resources
Version history

Installation

Follow the installation guide in the n8n community nodes documentation.

For self-hosted n8n: Settings → Community Nodes → Install, then enter n8n-nodes-data-validator.

Operations

The node validates every incoming item against the JSON Schema you provide and outputs one item per input item:

• Valid item → { "success": true, "data": }
• Invalid item → { "success": false, "validationErrors": [...], "data": }

Validation failures do not stop the workflow — route on the success flag (e.g. with an IF node) to decide how to handle invalid data. Binary data is passed through untouched.

If Property to Validate points to a property that does not exist on an item, the item is output as success: false with a single validationErrors entry whose keyword is propertyPath (and data: null), so a typo’d path is distinguishable from genuinely invalid data.

Node parameters

| Parameter | Description |
|—|—|
| JSON Schema | The JSON Schema each item is validated against. |
| Property to Validate | Dot-notation path of the item property to validate, e.g. body for webhook payloads. Leave empty to validate the entire item JSON. |

Supported schema features

Both draft-07 and draft 2020-12 spellings are accepted:

| Group | Keywords |
|—|—|
| Any type | type, enum, const, format |
| Numbers | minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf |
| Strings | minLength, maxLength, pattern |
| Objects | properties, patternProperties, additionalProperties, propertyNames, required, minProperties, maxProperties, dependentRequired, dependentSchemas, dependencies |
| Arrays | items, prefixItems, additionalItems, contains, minContains, maxContains, minItems, maxItems, uniqueItems |
| Applicators | allOf, anyOf, oneOf, not, if/then/else |
| Annotations | unevaluatedProperties, unevaluatedItems |
| References | $ref, $defs, definitions, $anchor, $id |
| Messages | errorMessage |

Additional behaviour:

• Formats: date, time, date-time, duration, email, hostname, ipv4, ipv6, uri, uri-reference, uri-template, url, uuid, regex, json-pointer, relative-json-pointer, byte, binary, password, int32, int64, float, double. Dates are checked against the real calendar, so 2023-02-30 is rejected.
• Custom messages via the errorMessage keyword, in both the string form and the object form ({ "required": { "email": "..." }, "_": "fallback" }).
• Strict schemas: a misspelled or unknown keyword is reported when the schema is compiled rather than being ignored, so a typo cannot quietly disable a rule.
• All errors are reported, not just the first one.
• Both parameters support n8n expressions and may resolve to different values per item; identical schemas are compiled only once per execution.

Differences from Ajv

Releases up to 1.2.0 used Ajv. n8n Cloud does not permit community nodes to carry runtime dependencies — not even bundled ones — so validation is now implemented in the node itself. The validationErrors output keeps the same shape (instancePath, schemaPath, keyword, params, message), and the differences worth knowing are:

• $ref must point inside the same schema document (#/$defs/..., #/definitions/..., #, or an $anchor). Remote URLs cannot be fetched during a workflow run and are rejected when the schema is compiled.
• An unknown format is rejected at compile time, so a typo such as emial fails loudly instead of accepting every value.
• multipleOf allows for floating point error, so 0.3 counts as a multiple of 0.1. Ajv’s default rejects it.
• $dynamicRef, $dynamicAnchor, $recursiveRef, $recursiveAnchor and $async schemas are not supported and are rejected with a clear error.

Usage

Example: validate a webhook payload. Set Property to Validate to body and use a schema like:

{
	"type": "object",
	"properties": {
		"email": { "type": "string", "format": "email" },
		"age": { "type": "integer", "minimum": 0 }
	},
	"required": ["email"],
	"additionalProperties": false,
	"errorMessage": {
		"required": { "email": "The email field is required" }
	}
}

Then branch on {{ $json.success }} with an IF node: true continues the happy path, false goes to your error handling (reply with a 400, send an alert, etc.). The details of each failure are available in {{ $json.validationErrors }}.

Compatibility

Requires n8n version 1.0 or above (Node.js >= 18.10).

Resources

• n8n community nodes documentation
• JSON Schema documentation
• Understanding JSON Schema — a practical guide to writing schemas

Version history

• 1.3.0 — Replaced Ajv with a built-in JSON Schema validator so the package has no runtime dependencies and passes the n8n Cloud package scan; added light and dark icon variants. See Differences from Ajv.
• 1.1.0 — Validate all incoming items (previously only the first); new Property to Validate parameter (previously hardcoded to body); added ajv-formats (format validation) and enabled ajv-errors (custom error messages); strict-mode schema compilation; explicit error when the configured property path is missing; fixed the package so the node loads correctly when installed from npm.
• 1.0.x — Initial release.

Upgrading from 1.0.x

Version 1.0.x always validated item.json.body. Since 1.1.0 the node validates the entire item JSON by default. If your workflow validated webhook payloads, set Property to Validate to body to keep the old behavior.

License

MIT