Building blocks
Reusable Schemas
Schemas let events and attributes share validation structures without repeating them. Define them once in schemas/, then reference them by key.
Define a Schema#
description: A non-empty identifiertype: stringminLength: 1The file path without its extension is the Schema key. Nested paths are supported, so schemas/customer/address.yml has the key customer/address.
Reference a Schema#
Use schema at the root of an event or attribute:
description: User IDtags: [web]schema: identifierReferences also work inside object properties and array items:
description: Order completedtags: [backend]type: objectproperties: orderId: schema: identifier customer: schema: customer relatedIds: type: array items: schema: identifierrequired: [orderId, customer]A Schema can reference another Schema, which makes larger definitions composable:
type: objectproperties: id: schema: identifier name: type: stringrequired: [id]Properties next to schema override the referenced definition at that location. This is useful for a local description or a stricter constraint:
schema: identifierdescription: Order IDminLength: 8Linting and building#
npx eventvisor lint validates Schema files, missing references, circular references, and the resolved event and attribute structures.
During npx eventvisor build, references are resolved and their definitions are inlined into the datafile. SDKs receive ordinary event and attribute schemas, so no runtime lookup is needed. A Target automatically gets the Schemas required by its selected events and attributes. Schemas are build dependencies and do not need their own include or exclude fields.
TypeScript code generation resolves the same references:
npx eventvisor generate-code --language typescript --out-dir src/eventvisorInspecting Schemas#
Schemas are first class project entities:
npx eventvisor list schemanpx eventvisor info schema identifiernpx eventvisor find-usage schema identifiernpx eventvisor lint --entityType schemaThe Catalog provides Schema list and detail pages, source history, usage relationships, and Target membership.
Projects using Sets place Schemas in each Set's own schemas/ directory.

