What it does

Send a JSON Schema and some data. Get back whether the data validates, with per-error detail when it doesn't. 

curl -X POST https://x402.agentutility.ai/json-schema-validate \
  -d '{
    "schema": {"type":"object","properties":{"name":{"type":"string"},"age":{"type":"number"}},"required":["name"]},
    "data": {"name":"Ada","age":38}
  }'
{
  "valid": true,
  "draft": "2020-12",
  "error_count": 0,
  "errors": []
}

$0.003 USDC. Pure compute via Ajv (MIT-licensed, reference JSON Schema implementation in JS), with ajv-formats for the format keywords (email, date, uri, uuid, etc.).

Why this is the missing endpoint

Every agent pipeline that uses structured LLM output has the same question after every call: did the model actually produce what I asked for? The LLM says "I returned JSON matching your schema." The schema says different.

You can validate locally. Most agent frameworks include some validator. But the agent's environment might not have ajv installed, the schema draft might not be supported, the format keyword handling might be inconsistent across runtimes. A paid endpoint that documents exactly which validator, which draft, which formats — and produces the exact same output regardless of where the caller runs — is worth $0.003.

It also handles a specific failure mode: an LLM outputs JSON that parses but doesn't match the schema. Without a validator, that bug slips through. With one, the agent catches it and retries.

What you get

A boolean. An error count. And a list of errors, each with:

  • instance_path — JSON pointer into the data where the failure happened (/users/3/email)
  • schema_path — JSON pointer into the schema constraint that failed (#/properties/users/items/properties/email/format)
  • keyword — which constraint failed (required, type, format, additionalProperties, …)
  • message — ajv's human-readable string
  • params — extra info specific to the keyword (which required field was missing, what value vs expected, etc.)

Use instance_path to surface the exact field the user (or the agent) needs to fix.

Draft support

Two drafts cover essentially every real-world schema. The endpoint defaults to 2020-12 (the latest stable). Pass "draft": "draft-07" if you have older schemas. Other drafts (draft-04, draft-06) work too if you set $schema on the schema document, but the official validators are draft-07 and 2020-12.

Format keyword

By default, formats are enabled via ajv-formats. So {"format": "email"} actually validates an RFC-flavored email address; {"format": "uri"} validates a URI; {"format": "date"} requires YYYY-MM-DD; and so on. Set "formats": false to disable — useful when you don't want format failures to flag, or when your schema uses custom format strings.

Caps

  • Schema: max 200KB stringified
  • Data: max 500KB stringified
  • Errors returned: 100 (with truncated: true flag when capped)

Below those caps the endpoint runs in milliseconds. Above, it returns 413.

valid_only mode

If you don't need the error detail — just yes/no — pass valid_only: true. Response shape becomes {valid, draft, error_count}. Tiny payload. Useful for high-volume gating.

What's NOT here

  • No "generate a schema from sample data" — different problem, different endpoint
  • No "convert this OpenAPI schema to JSON Schema" — different problem
  • No custom keywords. Ajv supports them but accepting user-supplied keyword code over the wire is a sandbox-escape on a paid endpoint.
  • No remote $ref resolution. Schemas with "$ref": "https://example.com/foo.json" won't auto-fetch — pass the referenced schema inline.

Pairs well with

  • json-yaml — convert YAML to JSON if your schema is in one format and your data in the other
  • extract-entities / structured-output endpoints — generate JSON, then validate it
  • regex-test — for string-shape constraints that JSON Schema's pattern keyword references

Call it.