Improvements to WebHooks Structure

[Anonymous]

As you may or may not know, I've created an integration between Jive and Marketo that uses WebHooks, and I see tons of value with just that piece of the integration.  However, we are nearly 6 months into our integration, and as we start to add more and more uses of WebHooks, we are finding that the rigidity in configuration is sending us down a path where there is a foreseeable management problem.

Currently, a WebHook is defined as a distinct Server Call (such ://host/context/resource?parameter=values…)  rather than a distinct resource ( ://host/context/resource )  … This means that in the event I want to call the same WebHook service with different parameters, I have to setup completely new WebHooks.  For things like integrating with VEvent, where we need to pass in new Ids each time a new event comes up…this means a constant creation of new one-off WebHooks that rarely gets deleted.

To help with this, I propose the following model be setup:

1.)  Create an independent "Host Record" responsible for (://username:password@host) information (this will keep users from having to copy/paste service credentials over and over again, and should those credentials change…it makes it one place to do it.

2.)  Alter the WebHook structure such that it has a "Host Record" as a child attribute and store (/content/resource/parameters names) as the WebHook.  Basically setting up the skeleton of the WebHook call.

3.)  Create a "Templated Parameter Values" Construct, that can store sets of Parameter Values for a specific WebHook.  Values may be 1234,ABC,xsd13 in the set, but providing a pretty name like "Welcome Email" to provide context to what they mean will help people select them from a drop down.   This allows the business is isolate business rules to a series of Named sets … such that the WebHook Flow reads…Call WebHook "Send Jive Notification" with Parameter Set:  "Welcome to Jive"

What's the Flow Like, beginning to End?

• Go to Admin > WebHooks > Create New
• First thing is to select an existing host and/or create a new one (modal pop-up I'd imagine, if create new)
• Add the Context + Resource Path Information … plus any parameter placeholders that are needed.  Perhaps syntax is {{webhook.param=foo}} or something similar.  This can be put into either the JSON payload or URL field.
• Save WebHook
• Add "Templated Parameter Values" to the new Webhook (can only be used with that web hook).  This could be something that looks like a raw JSON object, and/or a render UI with text inputs for every param in the WebHook.  Users could add in static value or reference lead/company variable information.
• Now, To Call the WebHook, simply create your Smart Campaign…select "Call WebHook" (drag to panel)
• After the WebHook is selected…the Flow Step renders an additional field that has a drop-down of "Templated Parameter Values" names to select from, or the user can select "add values manually" and the UI lets the person add a 1-off set of values.  Whether the input is free-form text or individual fields, I am indifferent.

The difference?  In the current paradigm we have 5 (soon to be 6-7) endpoints for WebHooks.  These are written to be very generic and rely on parameters to control their behavior.  In configuring our needs (we are just getting started)  we are using only 4 of the WebHooks End-Points and we have nearly 40 WebHooks defined.   In this new structure, it would be 1 Host Record … 4 WebHooks … and 2-8 "templates" per WebHook.  This makes a huge difference in maintenance, and the end-user experience when calling a web hook in a flow step.

That's all I had for now, but definitely wanted to get that out of my head.

[Anonymous]

We like the parameterization idea you outlined, but it is a fairly large project.   You can use this workaround in the meantime -

1. create a campaign folder to hold all your programs with webhook invocation
2. create folder level tokens which will be passed in as webhook parameters
3. create a new program for every campaign which invokes the webhook with a different parameter.  override the tokens with the value you want to use at the program level
4. The smart campaign would pick up the value of the token form the folder/program that it is in.

You can use this workaround in production today