Event Stream Source YAML Reference Beta
- free
- growth
- enterprise
9 minute read
This guide serves as a detailed reference for the CLI project YAML files that contain definitions of your Event Stream source resources.
Overview
In the context of the Rudder CLI (rudder-cli) tool, you can define Event Stream sources as YAML files within your project directory. The location and naming of these YAML files is flexible, as you can store the YAML files anywhere within the project’s root directory or subdirectories.
The Rudder CLI tool processes all valid YAML files within the project structure to recognize the defined resources.
Event Stream Sources
You can define an Event Stream source in the YAML file by setting kind to event-stream-source.
The spec parameter of the YAML file has the following structure:
| Property | Type | Description |
|---|---|---|
idRequired | String | Unique identifier for the source within the project. This parameter must be unique across all sources in the project. |
typeRequired | String | Source type identifier. See Supported source types for the list of acceptable values. |
nameRequired | String | Name for the source. It must be non-empty. |
enabled | Boolean | Determines whether this source is accepting events. Default value: true |
governance | Data governance configuration object | Contains data governance-related settings for the source. |
Data governance configuration
The governance object contains validation settings that control how the source handles any Tracking Plan violations:
| Property | Type | Description |
|---|---|---|
validationsRequired | Validation properties object | Contains validation configuration including Tracking Plan reference and violation rules. |
Validation properties
The validations object contains the Tracking Plan reference and violation handling rules:
| Property | Type | Description |
|---|---|---|
tracking_planRequired | String | URN reference to a Tracking Plan resource — the format is #tracking-plan:[tracking-plan.id], where tracking-plan.id is the spec.id value of the Tracking Plan resource. |
config | Violation rules configuration object | Contains violation rules for all event types. If not specified, default violation rules apply to all event types. |
You must have a Tracking Plan defined in your CLI project before you can reference it in a source configuration.
See CLI-based Tracking Plan Management for more information on creating Tracking Plans.
Violation rules configuration
The config object contains violation handling rules for different event types. Each event type configuration is optional; if not specified, default violation rules apply:
| Property | Type | Description |
|---|---|---|
track | Violation rules object | Violation rules for track events. |
identify | Violation rules object | Violation rules for identify events. |
group | Violation rules object | Violation rules for group events. |
page | Violation rules object | Violation rules for page events. |
screen | Violation rules object | Violation rules for screen events. |
Violation rules properties
Each violation rules object contains the following properties:
| Property | Type | Description |
|---|---|---|
propagate_violations | Boolean | Determines whether to add violations in event context. When enabled, violation information is included in the event payload’s context for downstream processing. Default value: true |
drop_unplanned_events | Boolean | Only applies to track configuration. Determines whether to drop events without a corresponding rule in the associated Tracking Plan.Default value: false |
drop_unplanned_properties | Boolean | Determines whether to drop properties that are not defined in the Tracking Plan for the event. Default value: false |
drop_other_violations | Boolean | Determines whether to drop events with any other validation violations. Default value: false |
If you set
drop_unplanned_events,drop_unplanned_properties, ordrop_other_violationstotrue, events that violate these rules are dropped and not forwarded to destinations.Make sure you understand the impact of these settings before deploying your source configuration.
Validation rules
Event Stream source references must resolve to existing resources
Rule ID: event-stream/source/semantic-valid
Examples
Event Stream source references must resolve to existing resources
Rule ID: event-stream/source/semantic-valid
Examples
Event Stream source spec syntax must be valid
Rule ID: event-stream/source/spec-syntax-valid
Examples
Event Stream source spec syntax must be valid
Rule ID: event-stream/source/spec-syntax-valid
Examples
Supported source types
The following table lists all supported source types and their corresponding type values:
| Source | type value |
|---|---|
| Java | java |
| .NET | dotnet |
| PHP | php |
| Flutter | flutter |
| Cordova | cordova |
| Rust | rust |
| React Native | react_native |
| Python | python |
| iOS | ios |
| Android | android |
| JavaScript | javascript |
| Go | go |
| Node | node |
| Ruby | ruby |
| Unity | unity |
Examples
Basic source configuration
This example shows a minimal source configuration without governance settings:
version: rudder/v1
kind: event-stream-source
metadata:
name: ios-source
spec:
id: "my-ios-source"
type: "ios"
name: "iOS Source"
enabled: trueSource with governance configuration
This example shows a source with governance configuration that links to a Tracking Plan and defines violation rules for different event types:
version: rudder/v1
kind: event-stream-source
metadata:
name: ios-source
spec:
id: "my-ios-source"
type: "ios"
name: "iOS Source"
enabled: true
governance:
validations:
tracking_plan: "#tracking-plan:ecommerce-tracking-plan"
config:
track:
propagate_violations: true
drop_unplanned_events: true
drop_unplanned_properties: true
drop_other_violations: true
identify:
propagate_violations: true
drop_unplanned_properties: true
drop_other_violations: true
group:
propagate_violations: true
drop_unplanned_properties: true
drop_other_violations: true
page:
propagate_violations: true
drop_unplanned_properties: true
drop_other_violations: true
screen:
propagate_violations: true
drop_unplanned_properties: true
drop_other_violations: trueSource with partial governance configuration
This example shows a source that only defines violation rules for track events, letting other event types use default rules:
version: rudder/v1
kind: event-stream-source
metadata:
name: web-source
spec:
id: "my-web-source"
type: "javascript"
name: "Web Source"
enabled: true
governance:
validations:
tracking_plan: "#tracking-plan:web-tracking-plan"
config:
track:
propagate_violations: false
drop_unplanned_events: false
drop_unplanned_properties: false
drop_other_violations: falseDisabled source
This example shows a source that is disabled and does not accept events:
version: rudder/v1
kind: event-stream-source
metadata:
name: test-source
spec:
id: "test-source"
type: "python"
name: "Test Source"
enabled: falseReference Tracking Plans
When configuring data governance validation, you can reference Tracking Plans using the following URN format:
tracking_plan: "#tracking-plan:[tracking-plan.id]"Where tracking-plan.id is the spec.id value of the Tracking Plan.
For example, if your Tracking Plan YAML file looks like this:
version: rudder/v1
kind: tracking-plan
metadata:
name: ecommerce-tracking-plan
spec:
id: product-tracking-plan
display_name: "Product Tracking Plan"
# ... rest of the configurationYou would reference it in your source configuration as:
tracking_plan: "#tracking-plan:product-tracking-plan"See more
- See Manage Event Stream Sources using Rudder CLI for feature overview, and the Event Stream Sources walkthrough for step-by-step setup
- See CLI-based Tracking Plan Management to create the Tracking Plans that you can reference in your Event Stream source configurations
- See Data Catalog and Tracking Plans YAML Reference for information about Tracking Plan YAML structure
- See Manage Destinations using Rudder CLI and Connection YAML Reference to send events from this source to a destination