MatchAPI is a JSON Schema-based format for describing financial messaging APIs.
It is intended for developers, integrators, exchanges, brokers, banks, and software vendors who need a machine-readable description of message structures, fields, data types, repeating groups, components, variants, and protocol-specific constraints.
The core schema is published as:
https://matchapi.org/schema/matchapi-core-1.0.0.json
Financial messaging APIs are often described in PDFs, spreadsheets, proprietary dictionaries, or protocol-specific formats. This makes it difficult to:
MatchAPI provides a neutral, machine-readable model for describing these APIs in JSON-compatible form.
This repository is primarily for developers who have received a MatchAPI JSON file and need to understand:
schema/
matchapi-core-1.0.0.json Core MatchAPI JSON Schema
docs/
getting-started.md First steps for developers receiving a MatchAPI file
user-guide.md Main user guide
core-concepts.md Schema concepts and object model
validation.md Validation guidance
publisher-guide.md Guidance for API publishers
licensing-and-attribution.md Licensing, attribution, and branding guidance
examples/
minimal-api.matchapi.json Minimal valid MatchAPI dictionary
README.md Notes on examples
LICENSE
NOTICE.md
ATTRIBUTION.md
CHANGELOG.md
CONTRIBUTING.md
A MatchAPI file is a JSON document with three required top-level properties:
name – the API name;version – the API version;content – the API model, including messages, fields, groups, components, and data types.A minimal valid dictionary can be found in:
examples/minimal-api.matchapi.json
To validate a MatchAPI file, use any JSON Schema validator that supports JSON Schema Draft 2020-12.
The schema file is:
schema/matchapi-core-1.0.0.json
See Validation for details.
Start here:
MatchAPI Core 1.0.0 defines a dictionary structure for financial messaging APIs. It includes:
It does not prescribe a particular programming language, runtime, validation tool, documentation generator, or transport implementation.
The core schema does not allow arbitrary additional properties at the top level or in most defined objects. Implementation-specific data should be carried through the schema-defined additionalData mechanism, where supported.
Please use GitHub Issues for schema feedback, documentation issues, or clarification requests.
Do not post confidential, proprietary, or client-specific API dictionaries in public issues.