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.

Upgrade if you’re using an earlier version.

Supported destination types

Use the type value in YAML. Every type below takes definition_version: 1.

Rudder CLI rejects any type outside this table. The dashboard catalog is larger than what you can define in CLI YAML.

Config reference pages are being added type by type. For a type marked Not yet documented, configure the destination in the dashboard and run rudder-cli import workspace — the imported YAML shows the exact key names for that type. See How to Import Workspace Resources.

Unverified destinations will be supported in the next iteration.

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 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.

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.

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:

• cloud — the SDK sends events to RudderStack, which forwards them to the destination from its servers.
• device — the SDK loads the destination’s own SDK and sends events to it directly from the device or browser.

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

For the concept in full, 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

rudder-cli import writes secret keys back as {{ .VAR }} placeholders rather than values, since the API doesn’t return secrets. Fill the placeholders in before the first apply.

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