Lead.Id as a Token

[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.