# Destination Type Reference for Rudder CLI

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.

Destination type Config reference
ActiveCampaign active_campaign Not yet documented
Amazon Redshift rs Not yet documented
Amazon S3 s3 Amazon S3 Destination Config Reference
Amplitude am Not yet documented
Attentive Tag attentive_tag Not yet documented
BigQuery Stream bqstream Not yet documented
Braze braze Not yet documented
Customer.io customerio Not yet documented
Facebook Conversions facebook_conversions Not yet documented
Facebook Pixel facebook_pixel Not yet documented
Google Ads googleads Not yet documented
Google Analytics 4 ga4 Not yet documented
Google BigQuery bq Google BigQuery Destination Config Reference
Google Cloud Storage gcs Not yet documented
HTTP Webhook http HTTP Webhook Destination Config Reference
HubSpot hs Not yet documented
Iterable iterable Not yet documented
Mixpanel mp Not yet documented
PostgreSQL postgres Not yet documented
PostHog posthog Not yet documented
S3 Data Lake s3_datalake Not yet documented
Snowflake snowflake Not yet documented
TikTok Ads tiktok_ads Not yet documented
Webhook webhook Not yet documented

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.

Source type Sources that resolve to it
web JavaScript SDK
android Android SDK
android_kotlin Android Kotlin SDK
ios iOS SDK
ios_swift iOS Swift SDK
react_native React Native SDK
flutter Flutter SDK
cordova Cordova SDK
unity Unity SDK
amp AMP Analytics
shopify Shopify
cloud Webhook sources and every server-side SDK — Node.js, Python, Go, Java, Ruby, PHP, .NET, Rust
cloud_source Cloud app sources
warehouse Reverse ETL sources

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:

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.

yaml 
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 is accepted by every destination type, keyed by local source type. Each source type maps to an array of consent entries.

yaml 
config:
  consent_management:
    web:
      - provider: oneTrust
        consents:
          - analytics
          - marketing
    react_native:
      - provider: custom
        resolution_strategy: and
        consents:
          - analytics
Field Required Value
provider Yes One of custom, iubenda, ketch, oneTrust
resolution_strategy When provider is custom and or or
consents No Array of consent category strings

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:

bash 
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