Connecting to Marketo with the REST Snap Pack

While SnapLogic’s REST OAuth account supports only OAuth 2.0, it does not work with Marketo’s OAuth implementation. To work with Marketo, you must authenticate manually using the REST Get Snap. In this pipeline, we pass the credentials in as pipeline parameters.

Note: This method does expose your credentials in the pipeline.



To simplify the process, define the following pipeline parameters

  • url: the REST API URL for your Marketo instance, like:
  • clientID: The clientID for API access.
  • clientKey: The client secret for API access.

Add a REST Get Snap (labeled Marketo Login here) and configure as follows:

  • For Service URL, toggle on the Expression button ( = ) and set the field to: _url + '/identity/oauth/token?grant_type=client_credentials&client_id=' + _clientID + '&client_secret=' +_clientKey

  • Remove the input view.

  • Validate the Snap and it will a return a response that contains an access_token and scope.

In this example, we follow the REST Get with a Mapper Snap to map the token outside of the array.

Using the Access Token

In subsequent Snaps, we pass this token as a header, rather than a query parameter because it simplifies paged operations such as Get Lead Changes. Here’s an example of a simple call which does this.

  • For Service URL, toggle on the Expression button ( = ) and set the field to: _url + '/rest/v1/activities/types.json'
  • Under HTTP Header, set Key to Authorization and Value with the Expression button ( = ) toggled on to ‘Bearer ‘ + $accessToken

Paged Operations

When you get to more complex operations, such as getting lead changes, you need to make two API calls: the first creates a paging token, and the second uses the paging token typically with the paging mechanism enabled in our REST GET Snap.

Get Paging Token

In this REST Get Snap (renamed Get Paging Token for clarity) is where you specify the query parameters. For instance, if you want to get lead changes since a particular date, you’d pass that in via “sinceDateTime”. The example provided uses a literal string, but could be a pipeline parameter or ideally one of a Date objects formatted to match what Marketo expects.

_url + '/rest/v1/activities/pagingtoken.json'

Configure Paging Mechanism

When calling Get Leads (via a REST GET Snap), a few things to bear in mind:

  • You need to pass “nextPageToken” as a query parameter, along with the fields you want back. Ideally, the list of fields should be in a pipeline parameter because they appear twice in this configuration.

  • The leads will be returned in $entity.result, which is an array. This field will not exist if there are no results, so you need to enable “Null safe” on a Splitter Snap after this REST Get.

  • Paging expressions for the REST Get Snap are:

    • Has next: $entity.moreResult == true
    • Next URL: '%s/rest/v1/activities/leadchanges.json?nextPageToken=%s&fields=firstName,lastName'.sprintf( _url, $entity.nextPageToken )

API Throttling

Marketo throttles API calls. Their documentation says “100 API calls in a 20 second window”. Since our REST Snap paging now includes an option to wait for X seconds or milliseconds between requests, use it whenever you are retrieving paginated results.


Marketo REST.slp (14.7 KB)

1 Like

Thanks Diane for wonderful document. We are in process of Integration from Oracle to Marketo. I am having problem in creating Account for Marketo. Can you please help us. A sample Pipeline would be wonderful.

I’ve attached the pipeline to the original post and also clarified that we are not able to connect with a REST account and ended up passing the the credentials as parameters. As noted, this does expose your credentials.

i got below error:
Failure: Failed to execute HTTP request, Reason: Connection reset, Resolution: Please check the Snap properties.
Can you guide me, Please?

Can you tell which Snap is failing?

This is not recommended approach as it exposed the credentials (which is a big no no). I humbly request SnapLogic consider enhancement to REST OAuth 2.0 account to support “client_credentials” and “password” grant type.

We understand that this is not optimal. We will look for a way to generically support obfuscation for types of use cases that leverage REST Snap. Thanks!