The apis.io JSON-LD section lists 7,381 contexts from 5,465 providers. About 85% declare schema.org, but few use it much. Of 373,037 term mappings we could parse, 40,413 (10.8%) point at a schema.org term. The rest point elsewhere, mostly at a namespace belonging to the provider. A context like that gives a term a unique name, but it does not tell a machine that one company’s customer is another company’s customer, which is the reason to use JSON-LD at all.
Who publishes
| Provider | Contexts | Note |
|---|---|---|
| Adyen | 855 | 11.6% of the collection, median 4 properties |
| HubSpot | 61 | |
| FactSet | 60 | |
| Palo Alto Networks | 54 | |
| Snowflake | 38 |
The other end is the norm: 5,188 providers have exactly one context. One caution about the word “publishes”. All 7,381 context files are served from artifacts.apis.io, the catalog’s own artifact host. They appear on the provider’s page because they describe that provider’s API. They are not a claim that the provider ships JSON-LD itself. Read them as a semantic layer built over each contract, unless the record shows otherwise.
What a good one looks like
Shopify’s context is the one I would copy. Product maps to schema:Product, Customer to schema:Person, Order to schema:Order, Address to schema:PostalAddress. Anything with no public equivalent stays in the shopify: namespace, such as Fulfillment and InventoryItem. It also brings in GoodRelations and Dublin Core, and 80 of its 104 counted terms reach schema.org. Square and Meta go further, with every one of 148 and 126 counted terms mapped to it. Stripe’s nests a context per type, so Customer.name maps to schema:name while Customer.id stays stripe:customerId, which is exactly the right distinction.
The weak version is common. Adyen’s main context sets @vocab to https://adyen.com/schema# and maps each term to adyen:, some with an xsd type. That is tidy and specific to Adyen, and it adds little beyond the OpenAPI schema it came from. Across its 855 contexts, 167 of 8,081 parsed terms (2.1%) reach schema.org. At the far end, Mocki’s has a class named GetV1D4867D8BB5D54A48A4Ab79131B5809B8Response, which is a URL turned into a type name. A rough pattern match finds about 58 contexts with class names like that.
What is ours to fix
Provider-namespace URIs like the Adyen one are identifiers, and I have not tested that they resolve. 259 records are truncated in the store, so they are outside these counts. 1,426 contexts report zero classes, including Stripe’s, which plainly defines Customer, and Square’s. Our extractor appears to miss some nested and schema-mapped definitions, so the class count on those pages undersells them.
Why an integrator or agent cares
An agent joining data across two APIs needs a shared meaning for the fields, and a JSON Schema only gives it a shape. A term mapped to schema:email carries that meaning between vendors. A term mapped to vendor:email does not, and neither does a context that declares schema.org and leaves it unused. The useful question for any context is how many of its terms point outside the provider.
Takeaway
The collection is broad and the semantics are thin. Mapping the twenty most common nouns in a contract to schema.org would change that for most providers. Browse them at apis.io/jsonld/.