This guide is for organisations publishing MatchAPI dictionaries.
Before publishing a MatchAPI dictionary:
schema/matchapi-core-1.0.0.json.Where possible, use stable identifiers for elements.
The schema supports:
uuid;id;name;variant.For protocol-specific elements, id can be used for identifiers such as FIX tags or other protocol-defined codes.
The keys section controls how elements are uniquely identified and referenced.
If you omit keys, the default primary key for most element types is name and variant.
For public dictionaries, define keys explicitly if your API uses:
Use variant when the same logical element has different forms for different use cases.
Avoid creating variants where a separate named element would be clearer.
The classifiers.categories and classifiers.sections collections are useful for documentation and human navigation.
For example, a publisher may group messages by business area or group fields by functional section.
Use additionalData for implementation-specific data and mappings.
Avoid placing sensitive internal details into public dictionaries unless they are intended for publication.
Use changeLog entries for definitional changes, deprecations, replacements, and significant editorial updates.
For public dictionaries, change logs help consumers understand the impact of a new version.
If publishing example dictionaries:
MatchAPI is intended to be consumable by any toolchain that can parse JSON.
Publishers should avoid presenting MatchAPI as dependent on a particular programming language or implementation toolkit.