Has anyone used preform fills using API? How did you do that?
We are looking to create this for our subscription center in our website and want to ensure that when someones email address is populated, their subscription settings are visible. We know Marketo has the cookies but we are looking for a permanent option incase the user clears their cache or is using a different browser, device, etc.
First of all, using REST/SOAP API calls in response to individual user activities is best left unconsidered, because it creates a DoS vulnerability. I know I say this all the time, but that's because it's a major issue. Any hacker can send 10,000 calls (that's a very, very small number) to a page that uses the API behind the scenes, and then your functionality.is done for. The APIs should be used for bulk actions happening server-to-server: that's where they shine and where daily call limits are (mostly) fine because you work in big batches.
Second, just to be clear, you can't use the APIs directly from the browser in any case. They need to be proxied via a back-end server, which means you need both front-end and back-end devs working on something like this.
It's better to work solely in the browser. If you want a quick-and-dirty solution for your case, embed a Marketo form (with prefill turned on) in an IFRAME. If the user happens to clear their cookies, then when they reenter their email address, say "please wait" while you submit the form, pause, then reload it from the server. When it reloads, it'll have their data. No API calls necessary.
Hi Sanford,
I'm working on a similar problem to Jessica. The suggestion of an IFRAME won't work for the use case... but I will keep that in the bag of tricks for later. 😃
Do you know if the RTP 'Get Visitor Data' function returns data that could autofill a form by chance? We don't have the RTP module currently for me to test. http://developers.marketo.com/documentation/websites/rtp-js-api/
Presently, we have a javascript AJAX call sending the Cookie Id to a server side .php script that queries MKTO and JSON encodes data. There's then a callback which autofills field values via jQuery to populate the form.
It's not the best I know. If it's any consolation, I am checking the .$_SERVER['HTTP_REFERER']; to make sure the request is from a company site, this still has holes though. Any insight appreciated.
thx!
I don't know anything about RTP (we don't have the module, either) but it seems unlikely.
Checking the Referer wouldn't make any difference, as a malicious user would just fake the Referer. The direct problem is the tight coupling of one form post = one API call. Like I said to another user, if the limit were 500,000+ (even 100,000+ for some poorly engineered sites) you could make the argument that the site itself couldn't handle that many page views in a day, so the API calls aren't the weak link. But any site worth putting on the net can handle 10,000 calls in a day, which means the API calls are a primary DoS vector. I wouldn't feel comfortable saying a site is rated at 9,999 calls per day before it starts breaking down.
Thanks for the thoughts!
You have some solid points on the DoS possibilities associated with the API calls required to autofill. I'm not sure of the best option other than keeping the function to lower traffic assets but those are obviously still at risk of malicious users.
What if we passed field values through the URI to the thank you page and had a script that stores the values in our own cookie for later autofill use? Have you done something like this before?
I'll see what I can find out about RTP from MKTO staff and will provide an update if anything looks hopeful.
thanks again!
Storing the values submitted from that same browser in a cookie (or, even better, in the browser's LocalStorage, but same idea) is easy. But that doesn't duplicate the functionality of prefill, since if someone uses a new device or clears cookies there's no longer a source for that data -- compared with true prefill which will work if the user simply becomes known again through a clicked link et al.
Please do let me know if RTP would be another approach.
Well, I have news, but not good news.
Here is what support said :
"The RTP API call will return only inferred information, and not the lead-specific information that you are seeking (email address, name, etc.). We do recommend the published solution on the Developers blog as a way to prefill external pages.
I see that your Community thread has a potential answer from another Community member. I would recommend testing any potential method with the use of a trained developer, to make sure you consistently get the results you're looking to pull, and to avoid any security issues with exposing Personally Identifiable Information.
"
Yeah, that's consistent with my impressions of RTP in that it's for anonymous segmentation.
BTW I do have a solution for this. It was actually part of my MUG talk last month. I've been wary of publishing it here, but I'm working with a couple of Community members on it. If you follow me back we can talk about it.
Sounds good! Consider yourself followed!