What's the effect of using the API to submit all form fills?

[Anonymous]

When Marketo went down a few months ago, we found ourselves in an unusual position where our forms were not rendering on our site. In response to this, my front end developer expressed a desire to transition to using the API to submit all form fills, which would allow us to continue to submit form fills in the event that Marketo forms go down. He also laments that Marketo slows down the rendering of our pages in general, and that removing the embedded form code from our pages will help significantly (we're talking milliseconds here, but I suppose every little bit matters). Lastly, this will allow us to control how we want to merge/create new records when existing users come into our system. Important to note that we do not use Marketo landing pages, and all of our Marketo forms are embedded.

My question is: how will submitting all form fills through the API affect the processing power of my Marketo instance? Our form fill volume is about 15k/month and fairly evenly spread out (with larger volumes coming during work days, but as a global company, those effects are limited). We also have a webhook limit of 50k per day and we're hovering around 1k currently. Are there any other concerns that I should be aware of here?

Thanks in advance!

[SanfordWhiteman · Accepted solution]

Switching to the REST API for forms is a fundamentally silly exercise, to the degree a comparison can even be made.

You'll be switching an endpoint that can handle 43,200 form posts per day per source IP to one that can handle 25,000 form posts total (emulating a form post requires 2 API calls). A tiny drop of malicious activity and you're done (and if you don't build for attacks in 2018, you're not building a pro site -- building for scale isn't about friendly visitors).

You'll be switching one point of failure for another: whatever you build to handle queueing and retrying form posts is new technology on your side.

You'll be switching an integrated form builder with built-in awareness of all Marketo fields and datatypes for something that needs to separately maintain a copy of your Marketo field schema.

You'll be switching built-in progressive profiling and known lead HTML (i.e. skipping forms for already-associated sessions) for, well, something that can't do those things.

The apparent latency of loading a Marketo form is due to the fact approved changes in Form Editor take effect in real-time (i.e. the form descriptor is reloaded for every session). If you're comfortable having changes take awhile to take effect (or until you forcibly clear a local descriptor) you can inline a Forms 2.0 form descriptor into your page -- this is exactly what Marketo LPs do, by the way -- and cache it for as long as you want. There isn't any additional latency in this case.

We also have a webhook limit of 50k per day and we're hovering around 1k currently. Are there any other concerns that I should be aware of here?

You have a REST/SOAP API limit of 50K, not webhook limit.  Webhook calls (which are outbound from Marketo) are not limited by number, only by practical turnaround on the wire.

[Amy_Goldfine]

We use website forms and push them to Marketo via API by adding to static lists. One warning I will give you is that you don't get acquisition program set automatically (adding someone to a static list is not one of the things that sets acquisition program). You have to add a smart campaign to every program to add an acquisition program. The previous people managing our Marketo instance didn't know this, and thus we have a huge chunk of people without acquisition program.

[SanfordWhiteman]

That's only because you used the wrong API endpoint. The Sync and Push endpoints set the AP. Note the Push session association part doesn't work as documented, though. So you still need Push + Associate as I assume you're now using List + Associate.

But since you should be moving away from the REST API anyway, it's not worth changing this.