As you dive into the world of webhooks for advanced database tasks, the number of webhook definitions in the Admin UI can get pretty crazy. I've seen instances with 100 different ’hooks!

 

Many webhooks do need to stand alone, but some come in pairs or groups. For example, an Add to Event Registration Counter webhook needs a companion Remove from Registration Counter. A Lookup in Suppression List webhook running against an external db likely means Add to Suppression List is also defined. And so on.

 

To consolidate webhooks and make the UI (and your code) more manageable, a cool trick is to send the {{Campaign.Name}} token along with the hook, so the remote service can decide which direction/action to take, and you only need to define one webhook to cover a group of related actions.

 

For example...

I have a webhook that maintains, in a Textarea custom field, all the Static Lists a lead is currently in. (This view is notoriously hard to get at, in both the UI and the API, unless you flatten it onto a field like this.) The field uses a semicolon-delimited format, as is typical for such things: Apples;Peaches;Pumpkin Pies.[1]

 

Naturally, the webhook is triggered on Added to List and on Removed from List. So I have those 2 campaigns set up with informative names:

 

ssss

ss

 

And the onRemove flow is exactly the same as the onAdd flow pictured above. They both call the same webhook, rather than there being 2 webhooks, one for each direction.

 

Then within the webhook itself, I can detect the direction because {{Campaign.Name}} is included in the payload (in addition to {{Trigger.Name}}, which is the List name):

 

ss

 

This I find infinitely more manageable than the alternative, since the onAdd and onRemove handlers sit right next to each other.

 

Obviously, the exact way your webhook service switches between different directions/modes depends on your architecture. Since this webhook uses JavaScript, there's a literal JS switch statement, while in other cases you might pass {{Campaign.Name}} in the URL path or query string (the dotted Program Name.Campaign Name could represent the dot-path to different Java class methods, that would be cool!).

 

 

Notes

[1] In this case, a single Static List can't have a semicolon within its name, for obvious reasons.  You can switch delimiters as necessary.