# 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

yaml

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

account_id

Required

Type: string

Description: Munchkin account ID of your Marketo instance, such as 123-ABC-456. RudderStack calls Marketo’s REST API on <account_id>.mktorest.com. The dashboard calls it Munchkin Account Id.

Notes:

At most 100 characters, and must not contain line breaks.
A {{ path || fallback }} template is accepted in place of a literal.

See Connection settings for where to find the Munchkin account ID.

client_id

RequiredSecret

Type: string

Description: Client ID of the Marketo REST API service RudderStack authenticates as — a custom LaunchPoint service tied to an API-only user.

Notes:

At most 100 characters, and must not contain line breaks.
A {{ path || fallback }} template is accepted in place of a literal.

Supply it as a {{ .VAR }} reference rather than a literal — see Secrets.

See How do I obtain the Marketo client ID and secret?.

client_secret

RequiredSecret

Type: string

Description: Client secret of the same REST API service.

Notes:

At most 100 characters, and must not contain line breaks.
A {{ path || fallback }} template is accepted in place of a literal.

Supply it as a {{ .VAR }} reference rather than a literal — see Secrets.

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.

track_anonymous_events

Type: boolean

Default value: false

Description: Send track events that have no userId. RudderStack then matches the lead by email, or by anonymousId.

Notes:

When false, a track event without a userId fails.
The dashboard’s note on this setting reads as though turning it on requires a userId on every track event. It’s the other way round: turning it on is what lets events without one through.

See Custom Activity Settings.

create_if_not_exist

Type: boolean

Default value: true

Description: Create a lead when no existing lead matches the event.

Notes:

When false, an event without a matching lead fails.

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

Type: array of objects

Description: Maps track event names to Marketo custom activities. A track event without a row here fails, so Marketo receives only the events you map.

Notes:

event — RudderStack event name.
marketo_activity_id — ID of the custom activity type, from Marketo’s admin settings. A digit string: quote it, since an unquoted number fails validation.
marketo_primarykey — event property whose value fills the activity’s primary field. An event without a value for it fails.

yaml

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

See Custom events.

custom_activity_property_map

Type: array of objects

Description: Maps track event properties onto fields of the event’s custom activity. The property named by marketo_primarykey fills the primary field and isn’t sent through this map.

Notes:

from — event property name.
to — API name of the custom activity field.

yaml

custom_activity_property_map:
  - from: product_name
    to: productName

See Custom activity property map.

lead_trait_mapping

Type: array of objects

Description: Maps identify traits onto Marketo lead fields. RudderStack already maps standard traits, such as email, firstName, and phone, on its own. Use this for custom fields, or to send a trait to a different field.

Notes:

from — trait name.
to — API name of the lead field.

yaml

lead_trait_mapping:
  - from: leadScore
    to: customLeadScore

See Supported mappings for the traits RudderStack maps on its own.

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

Type: object

Description: Maps each source type you connect to the mode its events reach Marketo in, using the modes in Source types.

Notes:

An entry is required for each source type you connect — see Connect a source.

yaml

connection_mode:
  web: cloud
  cloud: cloud

consent_management

Type: object

Description: Consent provider configuration per source type. The entry shape, accepted providers, and the rules on resolution_strategy and consents are shared across all destination types — see Consent management.

Source types

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

Source type	Connection mode
`android`	`cloud`
`android_kotlin`	`cloud`
`ios`	`cloud`
`ios_swift`	`cloud`
`web`	`cloud`
`unity`	`cloud`
`react_native`	`cloud`
`flutter`	`cloud`
`cordova`	`cloud`
`cloud`	`cloud`
`warehouse`	`cloud`

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:

yaml

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

bash

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