Calling Marketo REST API from a webook

[Grégoire_Miche2]

Dear all,

Has anyone tried to Call Marketo REST API from a webhook ? I gather that this is not possible because of the Authentication issue, but I just wanted to know if anyone had ever tried and what were the outcomes.

-Greg

[Anonymous · Accepted solution]

I have a question for you, what is the use case?  Are you using the webhooks to call a second instance of Marketo, or to update the same instance of Marketo?

If it is a different Instance, you can just use two webhooks, one to authenticate and one to perform the action.

If it is the same instance, then this will not be possible, you will have to call a webservice and then have that webservice relay the API calls.

[Grégoire_Miche2]

Hi Jamie,

It's the same instance.

I had come to that conclusion as well. Wanted to see if I had missed something.

Any idea of a platform to quickly and efficiently develop such web services ?

-Greg

[Kenny_Elkington]

AWS Lambda​ seems to be becoming a popular choice for these types of small single-purpose services.  Load-balancing, environment and server-provisioning are completely abstracted away so you can focus on create the service that you want, without the infrastructure overhead.

[SanfordWhiteman]

We ported our entire webhook infrastructure to Lambda in August 2014. Overall, I'm glad-to-very-glad about the move, erring on the side of optimism about them plugging some functional gaps this year. 

That said, Lambda alone is not the perfect fit for 'hooks that access reusable data such as an access token.  There is a disposable (=can be GC'd at any time) local environment in which you can persist data if you don't care about regenerating it when it goes away; I don't feel an access token falls into this category, although if you have a guaranteed very small # of calls per day it may be fine. Beyond that, you will need to add a persistence layer of your own (not within Lambda itself but probably somewhere else in the AWS ecosystem for speed).  Therefore, certain patterns that you might take for granted with, say, an existing PHP/MySQL setup where you never worry about persisting state (either in filesystem or db) become more complex with Lambda.  Still worth a strong look -- and yet containerized enterprise PHP hosting will be just as fast and scalable and may get you a familiar *MP stack built-in.

[Kenny_Elkington]

Agreed, if non-temporary persistence is needed, then it might not be the best choice.  A micro redis instance can probably suffice for any short-term caching, such as the access token, but I'm not speaking from experience here.

[SanfordWhiteman]

A micro redis instance can probably suffice for any short-term caching

Exactly!  We call out to AWS-hosted Redis. But it's annoying and can be a leap for people who are accustomed to some sort of local persistence, even a cached MySQL table or session files. 

[Grégoire_Miche2]

HI Sanford,

In fact, your are right, the AWS environment apparently comes with multiples services that, combined, probably offers all the necessary elements that are needed, including storage for persistent data (relational or noSQL), Identiy & Access Manageent and an API Gateway that seems to do a pretty good job mapping APIs.

-Greg

[SanfordWhiteman]

The ingredients are there!  At the same time, configuring Lambda+APIGW+IAM+Redis is kind of the ugly underside of Amazon's top-down embrace of microservices.  Not that I don't get it -- but like I said an enterprise-scale hosting service that gives you code, a persistence layer, and an HTTP endpoint at once may well be a better choice.  And even with Amazon APIGW (which can't be avoided if you want an HTTP endpoint) we are finding we have to route through another API gateway layer to get what we want.

[Anonymous]

You can build this using Python.