Generate a JSON Schema
Turn real examples of your data into a ready set of validation rules: give two samples, one with an optional value and one without, and that value comes out optional while the rest stay required. You pay per use, with no subscription.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
inferred from example payloads
Why describe your data at all
A formal description of your data lets a validator turn away a malformed record before it reaches your business logic, lets code generators build typed models, and lets you test a service automatically instead of comparing responses by eye. The trouble is writing it by hand. Anything beyond a flat list of values quickly becomes tedious, especially with nested lists, optional entries and mixed types, so many teams skip it or let it drift away from what their service really returns. Starting from real examples removes most of that work.
How your examples shape the result
The generator reads the samples you give it and infers the type of every value, the nested structure and which entries are required. Required means present in every example: if a value appears in one sample and is missing from another, it is marked optional. That is why the best input includes a couple of edge cases, such as a record with an optional value filled in and one without it. A single example also works, but every value it shows becomes required, and you can relax those rules afterwards. You pay per use, with no subscription.
FAQ
Can it detect formats like dates and emails?
Yes, it detects common unambiguous formats such as date-time strings and email addresses and adds the corresponding format annotation.
What happens on a failed request?
It retries up to three times automatically; if it still fails you receive a clear error and are not charged.
How many examples should I provide?
One is enough to start, but then every value it contains is treated as required. Add a second example where an optional value is missing and the generator marks it optional, because it no longer appears in every sample.
Does it handle nested structures and lists?
Yes. Nested structures and lists inside your examples are described level by level, which is exactly the part that is slowest and most error-prone to write by hand.
What can I do with the result?
A validator can use it to turn away malformed data before it reaches your business logic, code generators can build typed models from it, and you can test automatically that a service still returns what it promised.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/dev/json-schema-gen \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}'const res = await fetch("https://api.kit.forhosting.com/dev/json-schema-gen", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/json-schema-gen",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/json-schema-gen", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/json-schema-gen", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.json_schema_gen",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
422 | task_failed | The task failed after 3 retries. You are never charged for it. |
Technical notes
Nobody sits down and writes a JSON Schema for fun; it's the document you need after the API already exists and someone asks 'what does this response actually look like.' This endpoint reads one or more example payloads and infers a schema with correct types, required fields and nested structures, no hand-writing required.
The gap it fills
JSON Schema is what lets a validator reject a malformed request before it hits your business logic, what lets a client-generation tool build typed models, and what lets an API contract be tested automatically instead of by eyeballing responses. The trouble is that writing one by hand for anything beyond a flat object is tedious and error-prone, especially with nested arrays, optional fields and mixed types, so most teams either skip it or let it drift out of sync with the actual API.
What you send
You submit one or more example JSON payloads, ideally including a couple of edge cases such as a response with an optional field present and one where it's missing, since the API infers whether a field is required based on whether it appears consistently across your examples. A single example works too; it just produces a schema that treats every observed field as required, which you can loosen afterward if needed.
What comes back
A valid JSON Schema document with correct primitive types, detected formats where they're unambiguous, such as a string that looks like a date or an email, correctly modeled arrays and nested objects, and a required list built from what was actually consistent across your samples. It's returned ready to plug into a validation library or an OpenAPI definition without manual cleanup.
A brief note on the format itself
JSON Schema has gone through several draft versions since it was first proposed, and different drafts handle things like tuple validation and conditional schemas differently. The generated schema targets a current, widely supported draft by default, and produces the kind of document that validators like Ajv or equivalent tooling in other languages consume without modification.
Where it fits in a pipeline
It's a natural fit for contract testing: capture real response payloads from a staging environment, generate the schema, and diff it against the previous version to catch an accidental breaking change before it ships. It also saves time when documenting a legacy API that has payload examples scattered across old tickets and Postman collections but no schema anyone trusts.
Integration use cases
Contract testing in CI
A pipeline captures a live API response, regenerates the schema, and fails the build if a field that used to be required silently became optional.
Documenting a legacy API
A team with years of undocumented endpoints feeds saved Postman examples through the endpoint to produce schemas nobody had to write from scratch.
Client SDK generation
A generated schema feeds directly into a code-generation tool that produces typed request and response models for a mobile app.
Validating third-party webhooks
A team captures a handful of real payloads from a vendor's webhook and generates a schema to validate future deliveries before processing them.
Technical questions
How many example payloads do I need to send?
One is enough to get a working schema, but two or more, including an edge case with an optional field missing, produce a more accurate required-fields list.
Which JSON Schema draft does it target?
It targets a current, widely supported draft by default, producing a document that validators like Ajv and equivalent tooling accept without modification.
Is there a free plan to test the endpoint?
There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.
What's the price?
$0.003 per request plus $0.0135 per document, charged only when the task completes successfully.
Can I use the output directly in an OpenAPI spec?
Yes, the returned schema is valid JSON Schema and can be embedded in an OpenAPI components section with little to no editing.
Are my example payloads kept afterward?
No. Submitted payloads and generated schemas are deleted after the retention window and are never used for training.