1 of 1 people found this helpful
Segment is a good choice, with their v2 connector. Other ETLs as well. Webhooks are useful to trigger behaviours from one system into another or to request from updates, but are not intended for volume upserts.
It seems like I would need my company's platform engineering devs to create a webhook to connect our platform to Marketo.
If you mean a triggered connection from your database to the Marketo API best to not refer to that as a "webhook." That is, unless your platform already has an outbound webhook architecture built and you're simply plugging a new webhook definition into that (if so, you'd still need an intermediate webhook-to-REST-API gateway, since a true stateless webhook can't communicate directly with the Marketo API).
If your platform currently doesn't support outbound connections at all in response to events like customer deactivation, then it wouldn't be the right move to implement webhooks from scratch. You'd only have to (see above) create an additional gateway adapter for your own technology, which is wasted effort unless you need webhook support for some other purpose.
Instead, if you were building trigger technology from scratch, you'd build it to support the RESTful sequence: OAuth authorization request → token cache → data request. (It's the fact there are 3 steps that makes a true webhook unworkable, as a webhook means a single stateless connection to an outside service, with no "memory" of the event.)
With the above in mind, if your developers are building trigger tech from scratch, there's really no reason to send triggered data via the Segment API. Unless you have thousands upon thousands of deactivations per day, they should just push them to Marketo using the Marketo Push Lead API endpoint. It's one less network hop and data mapping step to worry about.