Destination Type Reference for Rudder CLI Beta

Every destination spec names a type, and that type decides which config keys the spec accepts. This section documents those keys, one page per destination type.

The rules on this page apply to every type. The per-type pages cover only what’s specific to that destination.

Destination support requires Rudder CLI v0.25.0 or later. Some types need a later version — see the Minimum CLI version column in Supported destination types.

Upgrade if you’re using an earlier version.

Supported destination types

Use the type value in YAML. Every type below takes definition_version: 1. The Minimum CLI version column in the below table shows the release these pages document for each type. On an earlier release the type is either unavailable or behaves differently.

Important considerations

• Rudder CLI rejects any type outside this table. You can define more destinations in the RudderStack dashboard than what you can define in Rudder CLI.
• To start from a destination you already configured in the dashboard, run rudder-cli import workspace — the imported YAML uses the same keys these pages document. See How to Import Workspace Resources for more information.

Config key rules

These rules hold for every destination type.

Keys are snake_case

Local YAML uses snake_case config keys. Rudder CLI converts them to the API’s camelCase at apply time. A camelCase key in the spec is treated as an unknown key.

Unknown keys fail validation

config accepts only the keys its type declares. Anything else fails rudder-cli validate with:

unknown config field "<key>"

A key that’s valid for one destination type isn’t valid for another. There are no shared optional extras beyond connection_mode and consent_management.

Omitting a key with a default is safe

Where a key declares a default, Rudder CLI fills that value in before it validates the spec and before the spec reaches the API, because the backend applies the same default when it stores the destination. Omitting such a key is equivalent to writing its default: it doesn’t produce a permanent diff on the next plan or apply, and it’s validated as though you had written the default — which can make another key required.

Keys without a default are sent only when you set them.

Some keys can’t change after the first apply

A key marked immutable on a type page is fixed once the destination exists. The API rejects an update that changes it.

Rudder CLI doesn’t check immutability locally. validate accepts the change and apply sends it, so the failure surfaces at the API rather than in your pull request. To change an immutable key, create a new destination instead.

Some keys aren’t in the dashboard

A key marked internal on a type page isn’t surfaced by the RudderStack dashboard. Rudder CLI accepts it so that an existing value survives an update, and so that a spec you import round-trips unchanged. Set it only if you know your destination needs it.

Source types

A destination declares the source types it accepts events from. Each type page lists its own set, drawn from the tokens below.

A source’s own definition resolves to exactly one token. Note that cloud and cloud_source are different tokens: a webhook or server-side SDK source resolves to cloud, while a cloud app source resolves to cloud_source.

Connection modes

A connection mode describes how a given source type connecting to this destination instance routes its events:

Note that:

• The connection mode is a property of the source-destination pair, not of the source or the destination alone.
• Two destinations fed by the same source can run in different modes.
• A source type supported in device or hybrid mode by one destination may be cloud-only on another.

For more information, see RudderStack Connection Modes.

Where the mode is declared

connection_mode lives in the destination’s config block, keyed by local source type — not on the connection spec.

config:
  connection_mode:
    web: device
    android_kotlin: cloud

Naming a source type the destination doesn’t support fails validation, and so does a mode that source type doesn’t support on this destination.

An entry is required for every source type you connect. Without one, validate reports:

destination '<id>' config has no 'connection_mode' entry for source type '<source_type>'

Consent management

consent_management is accepted by every destination type, keyed by local source type. Each source type maps to an array of consent entries.

config:
  consent_management:
    web:
      - provider: oneTrust
        consents:
          - analytics
          - marketing
    react_native:
      - provider: custom
        resolution_strategy: and
        consents:
          - analytics

Within one source type’s array, each provider can appear at most once. Only source types the destination supports are allowed.

Each consent string must be at most 100 characters, unless it’s written as a {{ path || fallback }} template, which is accepted at any length.

A plain value over the limit reports 'consent' must be at most 100 characters.

For the feature itself, see Consent Management in RudderStack.

Secrets

Each type page lists the keys Rudder CLI treats as secrets. Write them as {{ .VARIABLE_NAME }} references rather than literals, and supply the values at apply time:

rudder-cli apply --var-file secrets.vars.yaml

The YAML that rudder-cli import writes may or may not include secret keys. Before you apply, make sure every secret key your configuration needs is present and populated through variable substitution.

See How to Use Variable Substitution in Rudder CLI.

See more

• Destination YAML Reference for the spec envelope — id, display_name, type, definition_version, enabled, transformation
• Manage Destinations using Rudder CLI for the feature overview
• End-to-End Walkthrough: Destinations with Rudder CLI for step-by-step setup
• Connection YAML Reference to link a destination to a source