Lead.Id as a Token

[Anonymous]

I'd like to use Lead.Id in a webhook call that will do some work outside of marketo, update the lead record custom field, and then push the lead record into a campaign.  However I'm not seeing this field exposed as a token.  I could use email address but there is a chance of duplicates and updating the wrong lead record.  How are others handling this edge case?    

[SanfordWhiteman]

It's just {{Lead.Id}} -- you seem to already know this!

[Anonymous]

I haven't tested that but the documentation does not list that token and neither does the GUI when you go to insert a token, but I'll give it a go

[SanfordWhiteman]

It works, it's just not officially documented outside of Community posts.

[Owen_Millard1]

Tested to validate and asked the Docs team (articlefeedback@marketo.onmicrosoft.com) to include {{lead.id}} in the Tokens Overview section. Now included as of September 27, 2017.

[Anonymous]

I'm trying to use this {{lead.id}} but I'm not getting any value. Do I need to make some mapping form SF fields to marketo lead fields to access this as a token value? Thanks.

[SanfordWhiteman]

This is a Marketo-side field that always exists.

In what context are you trying to use the token?

[Anonymous]

In an email template to embed a link that will contain a unique identifier so that I can lookup the lead record (via rest api) when the user clicks on the link (I dont want to expose the users email for security and am looking for an id i can use to uniquely identify the lead in marketo). For example: 
<a href="http://marketing.com/Subscription.html?lid={{Lead.Id}}">Click to unsubscribe</a>

[SanfordWhiteman]

I'd worry far more about the DoS vulnerability of your architecture than about showing the lead their own email address.

But anyway, that token should work. Are you sending real emails or samples?

[Anonymous]

I'm testing right now, so I've only tried samples via the Email Template "Send Sample Email". This method doesn't show a value for the lead id that gets generated from the token. Thanks.

[SanfordWhiteman]

Always send real emails when testing tokenized content.

[Anonymous]

The other tokens used in the template rendered when testing. I created a mail from the template, but it's failing and gives no indicator why.

[SanfordWhiteman]

Some tokens do, some don't. I can't repro this with {{Lead.Id}} and a real email.

[Anonymous]

Thanks. It worked once I ran it as an email. Do you know of other unique identifiers that can also be used? A non-integer string perhaps?

[SanfordWhiteman]

The Marketo Unique Code and Marketo Unique Name are also specific to the lead but they don't work in an API context AFAIK (or at least no better than the ID). You could create a Base64 of the email address in a separate custom field.

Again, though, your goal seems to be to create a public page through which anybody can [a] look up anyone else's record by crawling IDs and [b] use all your API calls in the process, regardless of whether the record lookup succeeds, denying service easily to legitimate users.

While [a] is to some degree a necessary evil that's shared by Marketo LPs when you use lead tokens and/or form prefill, [b] is not a necessary evil and I can't recommend an architecture with this easy vulnerability.

[Anonymous]

The requirement is to create a custom unsubscribe link maps to our rest api, where the user can be identified from a not easily hacked token in the unsubscribe link. I'm looking for the best approach for implementing this. Thanks!

[SanfordWhiteman]

What do you mean by "our" API though? Is it the Marketo REST API? That's where you get your DoS vulnerability built-in.

If you've built your own CRM database with its own API to fetch lead details, then it would need to be primary-keyed on (or at least unique-keyed on) the Marketo Lead ID. Or you'd need to sync your IDs into Marketo custom fields (in bulk).

Building custom subscription centers that use the Marketo API is a no-no. You might use another system which syncs -- in bulk, not one-by-one -- with Marketo. Or use a Marketo LP (far more typical) which then pushes data to your system via webhook or some intermediate bulk sync layer.

[Anonymous]

The Marketo REST API. Rather than direct users to a LP from the unsubscribe link sent to them via our Marketo camapaigns, we want to send the user to an http endpoint on our server that will identify the user (means we need to securely identify them via a param in the Marketo mailer we send to them) and call the Marketo API and set a field value (unsubscribe = set a named field value to false), then do some other operations on our internal systems, and redirect the user to some other page after this data processing is done.

[SanfordWhiteman]

There's no reason to use the REST API to have an external subscription center. This can be done using the Forms 2.0 JS API without inviting a DoS.

[Anonymous]

It sounds like you have some knowledge of these Forms that I dont see detailed in the documentation: http://developers.marketo.com/javascript-api/forms/ . I believe you when you say you can do these via Forms 2, but just don't see how the requirements we have can be met by them - at least not from what is provided in the link I provided. With the REST API, I do have an understanding of how we can implement our requirements, although imperfectly.

[SanfordWhiteman]

Your requirement being setting Unsubscribed to true? This is basic Forms functionality. It doesn't get easier than that. Tying an Unsubscribe to a single provoking email is a (tiny) bit more work, but you're not doing this anyway.