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