SQL Syntax Checker

Overview

You pass SQL and a dialect; we check whether it parses at PARSE_ONLY level. We do not resolve table schemas, validate types, or run the statement. validationLevel in the response is always PARSE_ONLY. Do not use this when you need semantic, schema-aware, or runtime validation.

It's easy to say "SQL is validated" when you only mean "it parsed once." We label the level honestly so you know what you're getting.

When to use it

Scope

Non-goals

• Does not resolve schemas or table names
• Does not execute SQL
• Does not validate column types or constraints
• Does not prove the statement will succeed at runtime

Properties

Capabilities

Cost & billing

Flat rate per invocation

File handling

How we handle your data

Input schema

Output schema

API contract

curl -sS -X POST "$BASE/v1/execute" -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' -d '{"skillKey":"database.sql_validate_syntax","input":{"sql":"SELECT 1","dialect":"postgresql"}}'

import { Squillify } from "@squillify/sdk";

const sq = new Squillify({ apiKey: process.env.SQUILLIFY_API_KEY });

const { output } = await sq.execute("database.sql_validate_syntax", {"sql":"SELECT id FROM users WHERE active = true","dialect":"postgresql"});

Errors

Other limits

Limitations

• Does not resolve schemas or table names
• Does not execute SQL
• Does not validate column types or constraints
• Does not prove the statement will succeed at runtime
• Schema-aware or semantic validation
• Proving a query is safe to run in production

How to call

POST /v1/execute (requires authentication)

{
  "skillKey": "database.sql_validate_syntax",
  "input": {
    "sql": "SELECT id FROM users WHERE active = true",
    "dialect": "postgresql"
  }
}

Examples

{
  "sql": "SELECT id FROM users WHERE active = true",
  "dialect": "postgresql"
}

{
  "dialect": "postgresql",
  "statements": [
    {
      "type": "PLAINSELECT",
      "valid": true,
      "index": 0
    }
  ],
  "statementCount": 1,
  "findings": [],
  "valid": true,
  "_meta": {
    "parserProfile": "jsqlparser-5.3"
  },
  "validationLevel": "PARSE_ONLY"
}

{
  "sql": "SELECT FROM broken",
  "dialect": "postgresql"
}

{
  "dialect": "postgresql",
  "statements": [],
  "statementCount": 0,
  "findings": [
    {
      "details": {},
      "path": "/sql",
      "code": "SQL_SYNTAX_ERROR",
      "message": "SQL could not be parsed: net.sf.jsqlparser.parser.ParseException: Encountered unexpected token: \"SELECT\" <K_SELECT>     at line 1, column 1.  Was expecting one of:      \"WITH\"     <ST_SEMICOLON>",
      "severity": "error"
    }
  ],
  "valid": false,
  "_meta": {
    "parserProfile": "jsqlparser-5.3"
  },
  "validationLevel": "PARSE_ONLY"
}

Recommended use cases

• Reject obviously malformed SQL before submission
• Gate agent-generated queries in a CI step
• Confirm dialect tokenization before parameterization

Avoid for

• Schema-aware or semantic validation
• Proving a query is safe to run in production

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.

Tags