Data Validation Node
The Data Validation Node checks incoming data against a JSON Schema before passing it to downstream nodes. This ensures only well-structured, expected data flows through your pipeline, reducing errors and improving reliability.
Configuration
The settings dialog has two tabs, one per validated channel:
- Payload Schema
- Tools Payload Schema
- Configuration Schema
Enter a JSON Schema to validate the incoming payload. This tab is required — an empty schema here blocks all output (highlighted on the node until set).
Example
{
"type": "object",
"properties": {
"products": {
"type": "array",
"items": {
"type": "object",
"required": ["id", "title", "price"],
"properties": {
"id": { "type": "integer" },
"title": { "type": "string" },
"price": { "type": "number" }
}
}
}
},
"required": ["products"]
}
Optionally enter a second JSON Schema to validate the incoming toolsPayload. Leave it empty to skip toolsPayload validation entirely.
A "Block output if Tools Payload is invalid" switch controls what happens on failure:
- Off (default):
payloadstill forwards downstream; the (invalid)toolsPayloadis simply dropped. The failure is still visible in the Logs panel. - On: a toolsPayload failure blocks the node's entire output, exactly like a payload failure.
This is the full JSON Schema for the node's data configuration object, generated from the Zod schema used to validate the node at runtime.
{
"type": "object",
"properties": {
"validatePayload": {
"type": "boolean",
"description": "When on (default) or unset, payload is validated against payloadSchema. When off, payload passes through unvalidated."
},
"payloadSchema": {
"type": "string",
"description": "JSON Schema string used to validate the incoming payload. Left empty, payload validation is skipped (permissive)."
},
"validateToolsPayload": {
"type": "boolean",
"description": "When on, toolsPayload is validated against toolsPayloadSchema. When off/unset, toolsPayload passes through unvalidated."
},
"toolsPayloadSchema": {
"type": "string",
"description": "JSON Schema for toolsPayload, used when validateToolsPayload is on. Left empty, toolsPayload validation is skipped."
}
},
"required": [
"payloadSchema"
],
"additionalProperties": false
}
Example Usage
For example usage, see the Product Data Validation and Visualization workflow, which demonstrates fetching API data, validating it, and visualizing the results.
Common Use Cases
- API Response Validation: Ensure third-party API responses match expected formats.
- Input Sanitization: Prevent malformed or incomplete data from entering your workflow.
- Data Quality Assurance: Enforce required fields and data types.
- Error Prevention: Catch issues early and provide feedback for correction.
Best Practices
- Test your schema: Use tools like JSON Schema Validator to verify your schema.
- Be specific: Define required fields and types to catch subtle errors.
- Handle errors: Use downstream nodes to handle validation failures gracefully.
- Keep schemas up to date: Update schemas as your data structures evolve.
Troubleshooting
Common Issues
- Invalid schema: Ensure your schema is valid JSON and follows the JSON Schema standard.
- Unexpected validation errors: Double-check that incoming data matches the schema.
- Empty or missing fields: Use
requiredproperties to enforce presence of important fields.
Performance Tips
- Use for small to medium-sized data objects.
- For large datasets, validate only the necessary parts to improve performance.
- Test with sample data before running full workflows.
Supported Data Formats
- Input: Any JSON object or array, for both
payloadandtoolsPayload. - Output:
- Payload invalid → no output; an error is sent as feedback and shown in the Logs panel.
- Payload valid, toolsPayload invalid →
payloadforwards,toolsPayloadis dropped, unless "Block output if Tools Payload is invalid" is on, in which case it blocks like a payload failure. - Both valid (or toolsPayload schema unset) →
payloadandtoolsPayloadforward unchanged.
Why Use Data Validation?
Validating data before processing ensures that only well-structured, expected data flows through your pipeline. This reduces errors, improves reliability, and makes debugging easier—especially when working with third-party APIs.