[Feature Request] Webhook Provider

[ccollie]

Is your feature request related to a problem? Please describe. I was excited to see the DirectProvider, hoping I could use it as the base for sending arbitrary content to webhook endpoints. However it seems that the content is typed as a string.

Describe the solution you'd like A dedicated Webhook provider interface, or a genericized DirectProvider where we parameterize the content type.

Describe alternatives you've considered Currently the closest provider in functionality is the direct provider, so this is the only one I've considered.

Additional context If end-users have more complicated requirements (like retries, backoff, status code mapping) then it would make sense to have a separate provider type.

If there's a design put forth for such a provider, I'd be willing to devote some effort to implement it.

[scopsy]

Thanks for the feedback! Direct is indeed for more of a direct messaging channels, like slack, discord, telegram and etc...

Adding a WEBHOOK channel type is definitely something we can add and were planning to.

We can create a new entry in the ChannelType enum and an appropriate handler to manage the webhook with maybe something like got library which can manage basic retry policy.

One thing is to consider is what payload we will deliver to the webhook, in the notification template we can create a payload object with the object structure to pass to the webhook:

{
   "channel": ChannelTypeEnum.WEBHOOK,
   "payload": {
       "type": "{{type}}",
       "title": "{{channelTitle}}"
   }
}

Or on the other hand, we can pass a $payload to the trigger and pass the entire object. I prefer to manage the "payload structure" in the notification template just as if it was an email or other channel content.

About the retries and the more complex logic you are mentioning about could you explain more about your usecase? We are releasing soon an API to manage more complex workflows: https://github.com/notifirehq/notifire/tree/master/apps/api (Still WIP) and would love to know what we can add there aswell.

[ccollie]

@scopsy Thanks for the quick response! It's funny you mentioned got, as this is exactly what I'm using locally in the system I hope to replace with Notifire. With regards to payload, I had a similar idea, and in fact I have a payload mapper to do simple transforms. Here's a passing test:

 it('handles complex destination path', () => {
      const obj = {
        id: 1000,
        name: 'cheetos',
        tax: 10,
        price: 1000,
        count: 3,
      };

      const mapper = {
        id: 'id',
        'items[0].name': 'name',
        'items[0].tax': 'tax',
        'items[0].count': 'count',
        'items[0].price': 'price',
        'items[0].total': '{{multiply (get "count") (get "price")}}',
      };

      const expected = {
        id: 1000,
        items: [
          {
            name: obj.name,
            tax: obj.tax,
            count: obj.count,
            price: obj.price,
            total: (obj.price * obj.count).toString(),
          },
        ],
      };
      testMapper(mapper, obj, expected);
    });

As far as more complex logic, I think it's ok to start with what got supports natively, but with specific attention to features like signing.

[ccollie]

@scopsy if you add a WEBHOOK channel type I'd be happy to get started on a PR

[scopsy]

Oh got ya, you can add the WEBHOOK enum as part of your PR. Do you want to write down an outline of how you think of implementing the API for it here? What do you think of the proposal I made in the previous comment?

[ccollie]

Your proposal sounds good. Give me a day or so to put my thoughts together.

[scopsy]

@ccollie Amazing, let me know if you need any help 🎉

[MyWay]

This would be very interesting.

[came]

For me it would be even essential :/ Just a simple POST webhook channel/ provider I could add to the workflow sending over the entire payload. I would be fine building my notification and sending it. The use case is that I would like to send notifications to WhatsApp, Telegram and FB.

[scopsy]

Thanks for mentioning this @came. I think the implementation should be quite simple for this. Just need to find the time for this. Will create a new issue for this, as the original issue was related to the old stateless library which was deprecated. Will Link the new issue here.

[scopsy]

Tracked in #2958 2958