Webhook is Called - Response Contains: {{program.id}} or {{my.tokens}}?

[Anonymous]

Voted these up.

[Grégoire_Miche2]

Hi Osman,

there quite a few ideas in the community about the possibility to use tokens as filter and constraints parameters.

I once listed all the token enhancements that would be nice to get here: and this one is in the list.

-Greg

[Anonymous]

Thanks, Dan! Thanks, Greg! Nice to have all the sharpest minds in the room.

Any suggestions on how we might address this?

We've already built an external application that keeps tabs on the number of event registrants and closes registrations when we've reached capacity.

Maybe we'll just have that program send the notification? Bit of a bummer because I thought we could have Marketo do that, but if there's no other option...

[SanfordWhiteman]

Much as I love Webhook is Called, it doesn't have direct knowledge of the program context so it doesn't really work as a fully global trigger.

So you have a couple of options:

[1] Have the webhook response contain the program info (echoed from {{program.tokens}}).  Write them to a reusable lead field.  Then send a tokenized email picking up those tokens. This applies if you're trying to send email to program members (not really clear to whom you're sending the notification).

[2] If you're trying to send an alert to the de facto Program Owner, have a Resource Lead serve as that owner.  Pass all your Resource Leads through scheduled batch campaigns to check limits. Each lead only represents a single program so there will be no confusion about who/how to notify.

[3] Have program-specific Smart Campaigns (if you have a template program this becomes part of the scaffolding).

[Grégoire_Miche2]

Hi Osman,

A few ideas from the top of my mind. I did not gave them a second thought, so sorry if they are not that good

You could have the program external app prompt Marketo to send the email. For this, you setup a smart campaign in the program that sends the "sorry, no room left" email. Then, when the max number is reached, you have the program external app call this end point:

http://developers.marketo.com/rest-api/endpoint-reference/lead-database-endpoint-reference/#!/Campai...

You could achieve the same result with a form in a LP in the program and you would have to fill out that form programatically from your program external app. Then you could use the fills out form trigger to send the email.

-Greg

[SanfordWhiteman]

You guys really like those DoS attacks, huh? Don't get complacent... just because they're listening through your TV doesn't mean you're powerless.

[Grégoire_Miche2]

Why would there be a risk of DoS attack if it's a server to server REST call? I just wrote "program" instead of "external app", but when corrected, it probably makes more sense.

-Greg

[SanfordWhiteman]

Because presumably it's called in response to individual untrusted user actions (whether there's a server in-between doesn't matter if it doesn't do any throttling). But I'm not clear on who is really being notified here. If it's only one notification, ever to the Program Owner that would be ok.

[Grégoire_Miche2]

I get your point but in fact, I did not get into the details of saying the the rest call back from the app should be batched, but this was implicit form me. Obviously I was wrong

And my second idea uses the forms 2.0api for an almost real time call back, and this should be better, wouldn't it ?

-Greg

[SanfordWhiteman]

And my second idea uses the forms 2.0api for an almost real time call back, and this should be better, wouldn't it ?

Sure, 43,200 calls per day from the remote IP and no risk of breaking other integrations.

I would do this with the Resource Lead model, though. It just works better for me:

• Program membership change increments or decrements an external counter
• User form checks the counter before rendering
• Resource Lead checks the counter periodically and alerts Program Owner if you are over (or under -- another cool use case) a certain number of registrants