So, I've done several major ways of handling Marketo forms as they relate to WordPress: using free plugins, using a few LaunchPoint partners' plugins (which I won't really comment on due to conflict of interest—and something to keep in mind if/when those plugins' developers reply to this thread), using API integrations from plugins, writing an in-house plugin, using responsive iframes and just dumping the Forms 1.0 HTML/Forms 2.0 JS code on a page. To kind of break down the pros and cons:
Free plugins: For most small/medium installations (of both WP and Marketo), I really think Hutchhouse's Marketo Forms and Tracking is the way to go. It does the two things you need most: adds Munchkin out of the box and adds basic Forms 2.0 functionality with API prefill. If you're wanting to do anything advanced, either with the Forms API or with your own PHP, you're out of luck. There are other plugins out there with similar functionality to Hutchhouse's but I don't really think they're worth the time of day.
API integrations (aka "the Gravity Forms option"): I don't necessarily see Gravity Forms + Marketo API as an issue and I think it has its place for companies with a stronger web team than Marketo team, if you need to do some tricks that Gravity Forms handles better like adding payment gateways to your form, or if you need to send data to multiple locations. If you're not using Zack Katz's Gravity Form connector and developing your own connection in-house, you'll need someone who specifically knows GF's quirks for associating data.
In-house plugins: Sometimes you need to do really complex things with forms beyond their traditional scope and simultaneously need to let frontend users build and place forms; custom plugin work is usually the best way to solve these challenges. In the cases where I've built custom work, though, there's a few issues to address around both plugin development (hello error code 613, my old friend, I've come to yell at you again) and user training (setting up campaigns to interface with the in-house plugin.)
Responsive iframes: This is actually my preferred way of handling forms for quick dev times—build a faux LP hosting a form and use the NPR responsive iframe method to get cleanly hosted forms on your site. Getting the initial LP and scripting (so both parent and child page can interact together) can be a bit of a pain, though. If you're using both WordPress and another type of site concurrently it can make the process of deploying forms more streamlined.
Forms 1.0 HTML: I appreciate the control that Forms 1.0 offers in terms of being able to do anything you would with any non-Marketo form, because I romanticize Ye Olde Marketo. I also appreciate that I am very much in the minority on this view. 
Most people avoid this with good reason.
Forms 2.0 JS: While this method has the single fastest deployment (just paste and go!), you're going to wind up missing form pre-fill without some API workarounds. On the other hand, you have complete flexibility to use the Forms 2.0 API to create a lot of custom actions easily.
Like most things, the right choice for you and your site depends on what your outcomes are.
Grégoire Michel wrote:
Just pay attention to some so-called Wordpress Modules intended to "ease" the integration and that in fact use the server API on the client side. They are very dangerous as they expose Marketo connection info and would enable anyone to run a DoS attack on your Marketo instance.
Awww, Greg, that's what your WAF is for!
In all seriousness though, while I have seen this happen for other MAPs (InfusionSoft in particular) I've yet to see or hear any DoS attacks on a Marketo instance and would be interested in this beyond a "what if" scenario.
Honestly, I feel once you get into regulated industries you're almost better off just utilizing local storage for prefill, sending data to a PCI-compliant storage and setting up your own connection to any SaaS product, but that's just me and definitely off-topic here.
And that's if your legal team approves of prefill at all! 
But there are a lot of places (like SaaS and/or security tech vendors) who are mostly self-regulating but who don't pay attention to stuff like this even though it contradicts their mission statement, if nothing else. Drives me crazy.
The conversation did prompt me to take a look specifically at Hutchhouse though (since it does use SOAP) and while not horrifying in terms of exposed data could probably go for a RESTful rewrite.
If I were in a constructive mood, I'd say
- switch to REST with a Read Lead permission
- set a maximum # of calls per day (as much to allow cooperation between legit users of different integrations as to prevent abuse)
- better exception handling, specifically for rate limit exceeded
Hi Courtney,
Neither do I, but some of my customers (WW scale financial institutions with all the regulatory arsenal and the IT Security Office) are adamant about the idea of some even suggesting exposing Marketo Client ID or Client secret in a client-side code...
Furthermore, in these matters, better safe than sorry, IMHO
-Greg
.png)
- Copyright © 2025 Adobe. All rights reserved.
- Privacy
- Community Guidelines
- Terms of use
- Do not sell my personal information
Adchoices