Validate NDJSON
schema.validate_ndjson
Overview
You send NDJSON text, or a reference to a file of it, and we read every non-blank line as its own JSON value. Anything that will not parse, or that turns out to be an array rather than a record, is reported with the line it sits on. Hand us a JSON Schema as well and we check every record against it in the 2020-12 dialect, so one bad row out of a hundred thousand is easy to find. Each record must be on a single line; a pretty-printed document spread over many lines is not NDJSON.
Logs, exports, and streaming APIs all speak NDJSON, and a whole-file parse tells you only that something somewhere is broken. Line-scoped checking tells you which record to fix.
Reliability
Deterministic: the same input and options always produce the same problems in the same order. Without a schema we only check that each line parses and is not an array, so a bare number or string on a line passes — supply a schema if records must be objects. A schema is always read as 2020-12, whatever its own $schema keyword says, and references within it resolve while nothing outside it is fetched for you. We reject the call, and an unchanged retry will not help, when neither content nor fileRef is present, when maxRecords or maxErrors falls outside its range, when the file holds more than maxRecords records, when schema is not an object or cannot be compiled, or when a referenced file is missing, unreadable, or over 20000000 bytes.
Context footprint
Inline text is capped at 2097152 characters and a referenced file at 20000000 bytes; the response holds at most maxErrors short rows, so a badly broken file cannot flood your context. A successful call costs 1 execution credit.
When to use it
When you have newline-delimited records to check before ingesting or replaying them, with or without a schema to hold them to.
When the payload is one pretty-printed document, or when you want the records repaired rather than reported.
Powered by the networknt JSON Schema validator, a fast, spec-compliant engine for Draft 4 through 2020-12.
Scope
Non-goals
- We never repair or rewrite a record — that is schema.repair_json
- We never pull in another document, so send a self-contained schema
- We never treat a multi-line document as one value; that is schema.validate_json
Properties
Capabilities
Cost & billing
Flat rate per invocation
File handling
File limits
Constraints this skill applies to your input and generated files. The “Limited by” column shows the static source of each cap; none of these can be raised by upgrading your plan.
| Limit | Value | Limited by |
|---|---|---|
| Maximum size per input file | 19.1 MiB | Skill and platform maximum |
How we handle your data
What this means
This skill may receive sensitive content, but it does not target sensitive data and returns only a structured non-sensitive result.
Squillify guarantees
- Runs inside Squillify
- This skill runs inside Squillify.
- Payloads are not sent to an external service by this skill.
- Squillify does not permanently store submitted payloads.
- Telemetry records metadata only, not submitted content.
- Submitted payloads are not used for training.
- Submitted payloads are not reviewed by humans.
- This skill does not target sensitive data.
- The response does not contain submitted content.
Your responsibility
Squillify does not determine whether submitted content is sensitive. Your application is responsible for deciding what data it is allowed to submit. Your application is responsible for securing the response.
Input schema
| Field | Type | Required | Description |
|---|---|---|---|
| content | string | No | NDJSON text, one record per line, 1 to 2097152 characters. Required unless fileRef is provided. |
| fileRef | string | No | Tenant-owned NDJSON file reference; omit it to read content. When both are sent this one wins. |
| schema | object | No | JSON Schema applied to every record in the 2020-12 dialect; omit it for a structural parse-only pass. — unconstrained RFC 8259 JSON items. |
| allowBlankLines | boolean | No | Whether empty lines between records are acceptable; omit it for false. |
| maxRecords | integer | No | Most records to accept, 1 through 1000000; omit it for 1000000. Going past it rejects the call. |
| maxErrors | integer | No | How many problems to list, 1 through 100000; omit it for 500. |
Output schema
| Field | Type | Required | Description |
|---|---|---|---|
| valid | boolean | Yes | True when no problems were recorded. |
| recordCount | integer | Yes | How many non-blank lines were treated as records. |
| errorCount | integer | Yes | How many problems are in the errors list after the cap. |
| errors | array | Yes | Problems in file order, 0 through 100000 closed {line, code, message} objects. |
| schemaValidated | boolean | Yes | True when a schema was supplied and every record was checked against it. |
API contract
POST /v1/executecurl -sS -X POST "$BASE/v1/execute" -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' -d '{"skillKey":"schema.validate_ndjson","input":{"content":"{\"id\":1}\n{\"id\":2}\n"}}'import { Squillify } from "@squillify/sdk";
const sq = new Squillify({ apiKey: process.env.SQUILLIFY_API_KEY });
const { output } = await sq.execute("schema.validate_ndjson", {"content":"{\"id\":1}\n{\"id\":2}\n"});Errors
| Code | HTTP | Retryable | Description |
|---|---|---|---|
| VALIDATION_ERROR | 400 | No | The request payload failed schema validation. |
| UNAUTHORIZED | 401 | No | Missing or invalid API key. |
| SKILL_NOT_ACCESSIBLE | 403 | No | The API key is not granted access to this skill. |
| SKILL_NOT_AVAILABLE_FOR_PLAN | 403 | No | This skill is not included in your current plan. |
| PLAN_ELIGIBILITY_UNAVAILABLE | 503 | Yes | Plan eligibility could not be decided. Retry after backoff. |
| SKILL_NOT_FOUND | 404 | No | The requested skill or version does not exist. |
| TENANT_RATE_LIMITED | 429 | Yes | Request rate limit exceeded. Retry after backoff. |
| QUOTA_EXCEEDED | 429 | Yes | Plan quota exhausted. Retryable once the quota period resets. |
| EXECUTION_TIMEOUT | 504 | Yes | Execution exceeded the allowed time budget. |
Other limits
| Limit | Value |
|---|---|
| Recommended inline bytes | 32 KiB |
Limitations
- We never repair or rewrite a record — that is schema.repair_json
- We never pull in another document, so send a self-contained schema
- We never treat a multi-line document as one value; that is schema.validate_json
- A single pretty-printed JSON document (schema.validate_json)
- Records that legitimately span several lines
How to call
POST /v1/execute (requires authentication)
{
"skillKey": "schema.validate_ndjson",
"input": {
"content": "{\"id\":1}\n{\"id\":2}\n"
}
}Examples
Two valid NDJSON records
{
"content": "{\"id\":1}\n{\"id\":2}\n"
}{
"errorCount": 0,
"valid": true,
"recordCount": 2,
"errors": [],
"schemaValidated": false
}Malformed line reported with line number
{
"content": "{\"id\":1}\nnot-json\n"
}{
"errorCount": 1,
"valid": false,
"recordCount": 2,
"errors": [
{
"code": "PARSE_ERROR",
"line": 2,
"message": "Invalid JSON on line."
}
],
"schemaValidated": false
}Recommended use cases
- Check a log or export file before you load it anywhere
- Preflight a streaming payload one record at a time
- Find the handful of bad rows in a large generated file
Avoid for
- A single pretty-printed JSON document (schema.validate_json)
- Records that legitimately span several lines
Related skills
Composable with
Safety & privacy
- Runs without calling any external service.
- Your payloads are never stored permanently.
- Telemetry captures metadata only — never your payload contents.
- We never train models on your payloads.
- No human reviews your payloads.