Webhook for Discourse events

I’m writing up the specs for this in order to facilitate GSoC 2016 application

Specs

  1. A single page at “/admin/webhook” for admins to manage their webhooks
  2. Admins will need to provide a Payload URL which the webhook service will POST the event payload to.
  3. Webhook will POST all events to the Payload URL by default. We should allow admins to select individual events which they require.
  4. A Webhook can be activated and deactivated.
  5. Logs of the POST request as well as the response should be kept and made visible for admins.

For a start, I think the following events suggested by @phanimahesh is pretty reasonable.

19 Likes

I would love to see this in action! It’s been something I’ve wanted in Discourse for years now.

3 Likes

Are you saying that forum users will be able to subscribe to one or more published events? Or am I misunderstanding this?

1 Like

Renamed users to admins.

1 Like

Thanks :smile:

Now I need to go away and redigest this again. Sounds great tho’

We use a webhooks plugin for our slack integration over at Loomio, which seems like it might be a nice reference for someone looking to implement this.

https://github.com/loomio/loomio_webhooks

5 Likes

I’m writing a proposal for this project to apply for GSOC 16 and would like your help since I’m not completely familiarized with Discourse and its code.

The settings page will be close the one GitHub has, admins will be able to create webhooks by defining the payload URL and the events that trigger the webhook. After a webhook is created, there will be options to enable/disable, edit or remove it.

I’m thinking that each payload will have two sections: the first defines the payload with some fields like the timestamp and action that triggered the event; the second section contains the fields specific to each action.

Regarding the second section, we can use the existing serializers for the object(s) in question (user, topic, post, etc.) or we can choose carefully which fields will be sent.

Just to start the discussion, I’ve made a quick list of the proposed fields of each payload:

User

user_registered and user_activated

username, email, name, trust_level

trust_level_changed

username, old_trust_level, new_trust_level

message_sent

sender_username, receiver_username, msg_title, msg_content

Do we want the message content to be sent?

Another option is to define the required information of a user and use it whenever we’re referring to a user. For example, instead of sender_username we would have sender_info which has {ID, name, username, email, trust_level, …}.

Topic

Topic_created

ID, title, content, creator_username, categories

Topic_liked

ID, title, username, number_of_likes

Topic_{pinned,unpinned,archived,closed,invisibled,bookmarked}

ID, title, username

Post

Post_liked

post_ID, topic_ID, username, number_of_likes

Reply_posted

post_ID, topic_ID, username, content

Other

Auto_close_set

I don’t know what this one means…

Flag_raised

post_id, topic_id, reason


This is what I had in mind, please let me know if you had another idea :wink:

10 Likes

I’d like to add:

Badge Awarded

2 Likes

Could something like this be used for SES / email bounce webhooks too?

No, those Web hooks are from discourse to outside world. You want the opposite.

There are already bounces webhooks on core for three different providers, tough. Maybe try to craft a PR for ses?

Got it. Thanks. Still trying to figure out the terminology and where bits and pieces of the code are. :slight_smile:

Right now it is easier for me to do it externally in PHP/SQL. PR - One of these days…

1 Like

By the way, @fantasticfears has been working on getting webhooks in as part of GSOC :slight_smile:

The progress can be found at https://github.com/discourse/discourse/tree/gsoc_webhooks

7 Likes

Completed:

2 Likes