Marketo Destination Config Reference

Marketo is a marketing automation destination. RudderStack creates and updates Marketo leads from identify events, and records track events as custom activities on those leads, from its servers.

In a Marketo destination spec:

• type: marketo
• definition_version: 1

Sample configuration

version: rudder/v1
kind: destination
metadata:
  name: marketo-prod
spec:
  id: marketo-prod
  display_name: Marketo Production
  type: marketo
  definition_version: 1
  enabled: true
  config:
    account_id: 123-ABC-456
    client_id: "{{ .MARKETO_CLIENT_ID }}"
    client_secret: "{{ .MARKETO_CLIENT_SECRET }}"

    track_anonymous_events: false
    create_if_not_exist: true

    rudder_events_mapping:
      - event: Product Clicked
        marketo_activity_id: "100001"
        marketo_primarykey: product_id
    custom_activity_property_map:
      - from: product_name
        to: productName
    lead_trait_mapping:
      - from: leadScore
        to: customLeadScore

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

The above example records Product Clicked events as a custom activity and fails every other track event — Marketo receives only the events rudder_events_mapping names. Note that marketo_activity_id is a quoted string — see Mappings.

Config keys

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

Marketo accepts only identify and track events. RudderStack doesn’t deliver any other event type to it.

Connection

Lead matching

RudderStack finds the lead an event belongs to by its marketoLeadId external ID when the event carries one. Otherwise, it looks the lead up by the event’s email or, when there’s no email, by its userId — or its anonymousId when there’s no userId — stored in Marketo lead fields with those exact API names.

Create userId and anonymousId lead fields in Marketo before you send events. RudderStack looks leads up, and creates them, through those fields, so events fail without them.

Mappings

The three mapping keys connect your events to Marketo custom activities and lead fields. Create and approve each custom activity in Marketo first — see How do I create a custom activity in Marketo?.

None of the mapping fields is validated locally, so Rudder CLI accepts a row with a field missing — and every field is a string.

rudder_events_mapping:
  - event: Product Clicked
    marketo_activity_id: "100001"
    marketo_primarykey: product_id

custom_activity_property_map:
  - from: product_name
    to: productName

lead_trait_mapping:
  - from: leadScore
    to: customLeadScore

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: cloud
  cloud: cloud

Source types

Marketo accepts events from these source types in the mentioned connection modes:

Every source type is cloud only — events reach Marketo from RudderStack’s servers, never in device mode.

warehouse is the token a Reverse ETL source resolves to. Rudder CLI manages the destination’s warehouse entry — if the destination is connected to a Reverse ETL source, set connection_mode.warehouse: cloud in its spec, or apply removes it.

Rudder CLI can also declare the Reverse ETL connection itself, for the types listed under Supported destinations — see Manage Reverse ETL Connections using Rudder CLI.

The dashboard additionally offers Marketo to AMP and Shopify sources. Rudder CLI doesn’t manage those connections, so amp and shopify 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. Every type an event stream source can resolve to is supported here, so this check always passes.

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 'marketo-prod' config has no 'connection_mode' entry for source type 'web'

Marketo needs no additional config keys to connect a source of any type.

Secrets

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

config:
  client_id: "{{ .MARKETO_CLIENT_ID }}"
  client_secret: "{{ .MARKETO_CLIENT_SECRET }}"

export RUDDER_MARKETO_CLIENT_ID="..."
export RUDDER_MARKETO_CLIENT_SECRET="..."
rudder-cli apply

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

Note that:

• rudder-cli import writes only the secrets the API returns, as {{ .VAR }} references, and leaves the others out. Add any secret key it leaves out, then supply the variables before you apply — see Secrets.

See How to Use Variable Substitution in Rudder CLI.

Changes by release

No changes since this type became available.

For changes across every destination type, see Destination Type Changes by Release.

See more

• Marketo Destination for the API service setup, custom activities, and the traits RudderStack maps on its own
• Destination Type Reference for Rudder CLI for the rules shared across destination types
• Destination YAML Reference for the spec envelope