I have used it a few years back when designing a customer facing integration API, it was definitely good to be able to tell customers "here's the JSON schema, you can use these libraries to work with it, and use it to validate your requests for correctness before sending them to us". This said I felt expressing non-trivial constraints was quite verbose (things like if field X is set to 123 then fields Y and Z are mandatory, otherwise Y is not allowed, if X is set to 456 then no other field is allowed, ...) and hard to extend once written, I definitely felt the need for a "JSON schema generator" at times where I could've created a table of some sort and have it output the schema.

In another much more generic customer facing API I instead used a custom schema, as I needed to do other things that would not have been possible in it like embedding the API documentation in the schema so the front-end could display help on-the-fly and use the schema to dynamically generate forms. The advantage was also that being fully in control of the syntax I could create ways to express constraints like field X is valid only in searches, field Y is valid only in PUT/PATCH but not POST, etc. etc.

This said especially for straightforward APIs I feel JSON schemas are quite useful, being able to have a single source of truth on what your messages look like that you can share with front-end, back-end and customers is quite powerful. One thing is though that validation errors are not very user-friendly unfortunately. This was all around draft-04 time IIRC.

Yes, Snowplow uses JSON Schema extensively for event definition and validation (https://github.com/snowplow/snowplow/).

We used to, the idea being we could reproduce validation in JavaScript and Python. It kind of worked but it wasn't that clean. Ended up switching the server to Marshmallow schemas and just having more custom logic on the client side. It's a classic DRY ... this is where "duplicate" code was better for more control and less shoehorning.

We use it for validation for data that goes into our Postgres JSONB fields. It's a nice middle ground from forcing some unstructured data to be serialized/deserialized from protobuf to enforce its schema and some half-baked server side validation that lives in the application code.

Heroku does, and has built some nice open-source tools around it: https://blog.heroku.com/json_schema_for_heroku_platform_api

Yep, I use it heavily in FormAPI (https://formapi.io). One of the core features is schema validation, to make sure that PDFs can only be generated with valid data.

Yes, found it highly useful for a JSON-based configuration with a GUI for editing (towards not so technical users). The GUI was fully based upon the schema (i.e., dynamic by using things like the descriptions, types, and constraints for displaying / input validation).

The only thing that is counter-productive is the different schema iterations; at the time v3 and v4 have been different in some key areas. Haven't looked into v7 yet, but I hope its not "breaking as much" as v3 vs v4 did.

We did at one company I was at to do some code generation (specifically in Java[0]). Since we never ended up using it to generate client libraries the gains weren't as significant as originally planned.

[0]: https://github.com/joelittlejohn/jsonschema2pojo

Yes. A library I write (Keras-RCNN) uses it to validate input before starting the expensive augmentation process.

Yes, but many of the implementations are a nightmare to use if you have a complex schema and you want to return a meaningful, useful error to API users. To be fair, there can be ambiguity making it difficult for the library to return the correct error such as using "oneOf". Two things make a difference.

1. if/then/else which was added in Draft-07.

2. Custom errors. For Node, I use ajv and ajv-errors.

With the combination of if/then/else and custom errors, I have found that I can always return a single, useful error to the API user regardless of the schema complexity.

It's used to great effect by Vega and Vega Lite - see e.g. here: https://vega.github.io/vega-lite/examples/bar.html

See also my comment here: https://news.ycombinator.com/item?id=16407707

Yes, I use it to trigger actions on certain messages in one of our APIs instead of hardcoding them.

Incoming data -> is it a valid messages at all? -> if it is a message of type x, hand it over to class X -> if it is a message of type y, hand it over to class Y -> etc

I found that to be a very easy way to setup a general-purpose processing pipeline.

Yep, I used it to design and document a schema for a recent client of mine. What was really nice was the backend developer directly used the schemas to validate requests to our flask http server just by adding decorators to the routing functions. It was a great tool for us to coordinate API changes across front and back end teams.

Shameless self plug here, few months back I created a project https://www.contenttagger.com that gives you hints for Schema tags based on a parent Schema attribute. You can also validate it with Google devtools + Facebook graph.

Yes, we use it in Nakadi (https://zalando.github.io/nakadi/). It's an event broker platform based on Kafka, and we use json-schema for event validation.

I have done it a bit lately. To document to other companies what they can send or expect to receive. Trying to avoid having too much business rules in it, though, mostly just fields and their type. Compared to xsd for xml I find the tooling lacking.

Absolutely. When you have more than one team in different locations and cultures working on stuff in parallel you end up specifying your contracts. Many ways to do so, but nothing as binding as a JSON/XML Schema including samples.

Not since I discovered GraphQL. It's hard to imagine any other abstraction on top of REST APIs that packs as much robust functionality in something so easy to use.

We export massive amount of JSON downloads for our customers, with often different features enabled. So for each customer we generate a different schema for validation.

Yes because it documents what should go in the corresponding JSON, and some editors will automatically add completion.

jsonmerge is heavily based on JSON Schema.

https://github.com/avian2/jsonmerge