1 of 1 people found this helpful
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.