Customer.io Destination Config Reference Beta

Customer.io is a messaging and marketing automation destination. RudderStack sends events to Customer.io’s APIs from its servers, or through Customer.io’s own SDKs in device mode on web, Android, and iOS.

In a Customer.io destination spec:

• type: customerio
• definition_version: 1

Sample configuration

version: rudder/v1
kind: destination
metadata:
  name: customerio-prod
spec:
  id: customerio-prod
  display_name: Customer.io Production
  type: customerio
  definition_version: 1
  enabled: true
  config:
    site_id: "{{ .CUSTOMERIO_SITE_ID }}"
    api_key: "{{ .CUSTOMERIO_API_KEY }}"
    datacenter: US
    api_version: v2
    user_id_identifier_type: id
    device_token_event_name: Device Token Registered

    send_page_name_in_sdk:
      web: true
    data_use_in_app:
      web: false
    auto_track_device_attributes:
      android: true
      ios: true
    background_queue_min_number_of_tasks:
      android: "10"
    background_queue_seconds_delay:
      android: "30"

    connection_mode:
      web: device
      android: device
      cloud: cloud
    consent_management:
      web:
        - provider: oneTrust
          consents:
            - marketing

The above example sends server-side events through the v2 API, and connects web and Android sources in device mode, where the SDK settings apply — see Device mode.

Config keys

config accepts only the keys listed below. The shared config key rules cover unknown keys, defaults, and immutability.

Connection

Cloud mode

These keys apply to events sent in cloud mode. They have no effect on device-mode delivery.

Device mode

These keys configure Customer.io’s SDKs, so they apply only to sources connected in device mode. Each is keyed by the source type it applies to.

auto_track_device_attributes:
  android: true
  ios: false

Event filtering

Client-side event filtering applies only when connection_mode.web is device — the dashboard shows these controls only then, and the SDK is what applies the filter. Rudder CLI accepts the block in any mode, but it has no effect on other connections.

Per-source keys

Both keys are objects keyed by the local source type — the tokens listed under Source types. A key naming a source type this destination doesn’t support fails validation.

connection_mode:
  web: device
  android: device
  ios: cloud

Source types

Customer.io accepts events from these source types in the mentioned connection modes:

web, android, and ios offer device mode. The Kotlin and Swift SDKs — android_kotlin and ios_swift — are cloud only. See Customer.io device mode.

The dashboard additionally offers Customer.io to AMP, Shopify, and Reverse ETL sources. Rudder CLI doesn’t manage those connections, so amp, shopify, and warehouse are invalid here.

Connect a source

An event stream connection to this destination is checked against two rules at validate time.

The source’s type must be supported. A source’s type resolves to one of the tokens above before the check — a JavaScript source resolves to web, and webhook and server-side SDK sources resolve to cloud. An unsupported type reports:

destination 'customerio-prod' (type 'customerio') does not support source 'my-source':
source type 'amp' is not among supported source types: android, android_kotlin, ...

The destination config must carry a connection_mode entry for that source type. This lives on the destination spec, not on the connection spec. Without it:

destination 'customerio-prod' config has no 'connection_mode' entry for source type 'web'

Customer.io needs no additional config keys to connect a source of any type, in any mode.

Secrets

api_key and site_id are the secret keys. Write each as a {{ .VAR }} reference and supply the value at apply time:

config:
  site_id: "{{ .CUSTOMERIO_SITE_ID }}"
  api_key: "{{ .CUSTOMERIO_API_KEY }}"

export RUDDER_CUSTOMERIO_SITE_ID="..."
export RUDDER_CUSTOMERIO_API_KEY="..."
rudder-cli apply

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

Note that:

• 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.
• In web device mode the site ID is embedded in the page’s JavaScript, so masking it protects your YAML, not the value itself.

See How to Use Variable Substitution in Rudder CLI.

See more

• Customer.io Destination for the API key and site ID, and the per-mode settings
• Destination Type Reference for Rudder CLI for the rules shared across destination types
• Destination YAML Reference for the spec envelope