Web to Lead documentation?

[Robb_Barrett]

Hi all - I'm trying to find documentation for Web to Lead using forms and the leadCapture/save method.  I know this is an old method but I need to recreate such a service in a new instance of Marketo and they were originally created before my time.

I have a couple of things I want to verify, one of which is the form that's used: does it have to have the fields being passed as hidden fields with parameter values or can I use just a blank form?  I'm working with a vendor so I don't want to waste a lot of time testing things.

[Dan_Stevens_]

I believe they removed the documentation from the Developers site since it's encouraged to use the Forms 2.0 API (which I know you're familiar with).  But if you need to use this approach, the POST URL looks like this:

https://[yourdomain.com]/index.php/leadCapture/save2?FirstName=[FIRST]&LastName=[LAST}&Email=[EMAIL]&formid=1234&munchkinId=xxx-xxx-xxx

And no, your form does not need to contain any fields.

[Robb_Barrett]

Thanks, Dan! My vendor is not familiar with the REST API with Marketo and says they can go live faster if we use this method. My hope is that it's not deprecated any time soon.

[Robb_Barrett]

Hey Dan - I think this might be wrong.  I tried the URL you provided and it failed.  What worked is this:

https://app-podId.marketo.com/index.php/leadCapture/save

[SanfordWhiteman]

They both work -- it just depends on what you use them for (and sending the right fields).

/save is the legacy Forms 1.0 and noscript endpoint. It sends a direct 301 redirect to the Thank You URL, which is handy when using it from 3rd-party forms that can't parse the JSON response from /save2. /save also is the one that used to work for loopback connections in webhooks, though that's now become unreliable across pods/instances (/save2 never worked for that case).

/save2 is the Forms 2.0 endpoint used by all public-facing forms, so it certainly works. It returns a JSON payload that can then be parsed to determine follow-up and outcome. You can access it either via {pod}.marketo.com or via a landing page domain. However, you can't make an SSL connection to your LP domain unless it actually has a cert installed.

In both cases you shouldn't be sending the fields on the query string (as you have to with an emulated POST-as-GET).  They should be POSTed as standard form fields.

[Dan_Stevens_]

/save also is the one that used to work for loopback connections in webhooks, though that's now become unreliable across pods/instances

Sandy, we currently use the following endpoint in our purposeful duplicate webhook:

http://localhost/index.php/leadCapture/save

So far, it's been fairly reliable (moreso now, after doing some testing once we found some issues a while back). I've been running tests every hour for over a week now on a test lead record - where I create a duplicate using the following payload:

Would using our cname domain (in place of localhost) be any more reliable, e.g., https://pages.avanade.com/index.php/leadCapture/save

[SanfordWhiteman]

Would using our cname domain (in place of localhost) be any more reliable, e.g., https://pages.avanade.com/index.php/leadCapture/save

The LP domain won't work at all last time I looked, so loopback (localhost) is your only choice.

In theory, hitting the LP domain would be more reliable, because it would mean the server running the webhook would always find the server(s) running your instance, even if they were different boxes (localhost will always hit the same box that's running the webhook).  But it doesn't work at all due to internal DNS or routing conflicts (or both).