Webhook for Discourse events


(Alan Tan) #1

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


  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.

Webhooks/Push Notifications
Event Hooks for Discourse
(Robin Ward) #2

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


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

(Alan Tan) #4

Renamed users to admins.


Thanks :smile:

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

(James Kiesel) #6

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.

(Andre Pereira) #7

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_registered and user_activated

username, email, name, trust_level


username, old_trust_level, new_trust_level


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, …}.



ID, title, content, creator_username, categories


ID, title, username, number_of_likes


ID, title, username



post_ID, topic_ID, username, number_of_likes


post_ID, topic_ID, username, content



I don’t know what this one means…


post_id, topic_id, reason

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

Webhooks feedback
Can you pass a user field value through a webhook?
(R3trosteve) #8

I’d like to add:

Badge Awarded

Webhooks feedback
(Shri) #9

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

(Rafael dos Santos Silva) #10

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?

(Shri) #11

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…

(Alan Tan) #12

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

(Erlend Sogge Heggen) #13


(Erlend Sogge Heggen) closed #14