About JSON Mint

It always bothered me that there was no JSON schema tooling suited to how architects, engineers and technical product managers actually design APIs: together, while discussing them. An example-driven 'living design' keeps the focus on the product rather than the fiddly details of the JSON, and keeps the conversation going.

I had a lot of fun creating this. It isn't perfect or complete, but the feedback so far (and the bug reports, thanks!) tells me it's a good start. Bug reports and suggestions are always welcome.

David Green, Llingr Software Ltd, jsonmint@llingr.io

Specification-Last Schema Design

Start from real JSON and refine it into a specification, instead of writing the schema first.

Make ambiguous fields concrete

Every schema tool can turn example JSON into a schema, but an example is ambiguous. It can't say whether a field may be missing, whether it can be null, that a count is never negative, or that a status is one of four strings. In JSON Mint you settle that on the field itself. Put the cursor on a field and the inspector lets you:

• mark it Required, Nullable or Omit when null;
• give it a format (date-time, uuid, email and others), bounds, a pattern or a list of allowed values;
• say what else it can also be;
• give it a default and a description;
• flag it read-only, write-only or deprecated.

The schema updates as you work. If the example stops matching a rule you've set, you're told before you save.

Defaults from field names

Call a field accountId and it's a UUID. createdTs is a date-time, and durationMs is a non-negative number of milliseconds. Accept the suggestion and a real value goes in: a fresh UUID, or the current time. Tokens such as :uuid, :ts and :name do the same anywhere, and Cmd/Ctrl+B re‑rolls the value under the cursor. Define entities, such as a customer or an order, with a pool of sample records, and typing one's name inserts a realistic record.

Compose from shared resources

Define a resource once, such as an address or an amount of money, and compose it into any API request, response or event. JSON Mint records where each one is used.

Live linting

Field names are checked as you type, against the naming convention you choose (camelCase, snake_case and others) and a maximum length. JSON syntax is checked too.

APIs and events, exported

An object can be a REST request and response, with method, path, query parameters, headers and status codes. It can also be an event on a Kafka topic, with its key and headers. Export the workspace as OpenAPI 3.1 or AsyncAPI 3.0, preview it in the app, and download it as YAML or JSON. Comments you leave in the example become descriptions in the exported spec.

Tags and filters

Tag objects by product, service and feature, then filter the list by tag, kind or name.

Saved, shared, and private when you need it

You can start without an account. When you save, your work is stored in a workspace, and you choose who can see it:

• open: anyone with the link can edit;
• public: anyone with the link can view, and only members can edit;
• private: invite-only.

Sign-in is by passkey. Owners invite people as editors or guests with a share link. They can change roles, remove members, and switch a workspace between public and private at any time.

Infrastructure

JSON Mint runs on the generous free tiers and credits of Cloudflare, Google and Databricks. That runway isn't infinite, so I might add a small paid plan (around $2.50 a month) purely to cover infrastructure and payment costs, or take on sponsorship, which would always be low-key. If you'd like to sponsor JSON Mint and help keep it free, get in touch at jsonmint@llingr.io.