Webhooks feedback

(Semaphorism) #16

Ahh thanks :slight_smile:
I can always setup a IP tables rule to deny outside access to it anyway, or just whitelist the IP on the node server itself. That does work using the external IP of the server as well!

(Daniel Marquard) #17

Great work on this! I’ve set one up to talk to a PHP script I’m working on, but I’m having trouble differentiating the event data. I have the webhook configured to trigger on post and topic events, but the payload doesn’t contain the event names you mentioned in your topic on setting up webhooks.

Also, I noticed that the post event trigger says in Discourse that it fires when posts are edited and deleted, but this wasn’t the case on my website. This is not important for my use case, just thought I’d let you know.

(Daniel Marquard) #18

Oh! I just realized that the event name is sent in the X-Discourse-Event header. Perfect.

(Bala V) #19

I don’t agree with this. We are integrating discourse with a healthcare mobile app. One of the main features is to notify all the contributors of a specific topic whenever there is an “event” on it. With more than 50K users in the platform, the payload size is really huge. Specifically, this is due to the “actions_summary” field in the payload. If there is a way to filter it out, the payload size reduces drastically and becomes manageable.

(Rafael dos Santos Silva) #20

But are you sending this hook to 50k endpoints? Or to another system that parses and then send the notifications? Couldn’t this system filter the fields?

(Bala V) #21

I am not sending this to 50K endpoints. Another system will parse and send the notifications. I would prefer not to deal with large payloads (unless you are in a very closed and tightly coupled environment). But if you are talking about a scale of 1M users, it is just not efficient. So some option to filter would make it really efficient & work for all use cases.

(Semaphorism) #22

There doesn’t seem to be a way to differentiate between what website is sending the webhook, is it possible to add a domain in the discourse config to the request headers, something like x-discourse-domain? or maybe something unique to each instance of discourse?

Use case:
I have a Discord bot that is going to post to when someone creates a topic or reply, and notifies certain discord servers. I am currently running 2 discourse instances on my server, and they both have webhooks to the same API on the bot, but there appears to be no difference in request headers.

(Daniel Marquard) #23

I love the webhooks feature! I have some critique to offer, though.

First, it seems like the permalink/URL would be central to the post/topic events, but this is not included in the payload. It’s not a big deal since I was able to build the URL myself from the properties provided, but it seems logical that this should be added for topics and posts in the post stream.

Second, it looks like only the cooked posts are delivered. Receiving the raw posts could be useful, too, if that’s possible, especially when used in an application that doesn’t parse HTML.

While I appreciate the copious number of properties sent from topic and post webhooks, some of the data seems irrelevant, like can_act, can_edit, and unseen, among others. Not an issue at all, but some fields may be unnecessary.

Two webhook events sent for some new topics
(Burke) #24

Webhooks is a great addition to Discourse! I’d like to +1 @r3trosteve’s earlier comment:

Triggering webhooks on a “Badge Event” would be incredibly useful. We could use these to toggle on permissions in external applications when badges are earned in Discourse (e.g., you can edit our wiki once you’ve earned trust level 2 in our forum).

Extra credit: reduce unnecessary traffic by allowing badge events to be scoped to specific badge(s)


First of all, just want to say thanks! This looks really fantastic!

I was playing around with it earlier today and noticed a couple of things:

  1. Post Event doesn’t work on edits.
    The description on the webhooks page says “When there is a new reply, edit, deleted or recovered.” but I can’t get it to work with edits for some reason…

  2. Payload format?
    The Setting up webhooks howto makes it looks as if the a Post event will trigger a payload with just the relevant post, however I seem to be getting the whole topic and post_stream in my payloads. Is this expected or am I doing something wrong?

(Burke) #26

@fantasticfears, do you think adding Badge Event to webhooks would be hard? Would it take a lot more than adding support for user_badge_granted and user_badge_removed events to web_hooks.rb?

This feature would be a game-changer for the OpenMRS community. :smile:

(the Camel’s nose … “you give 'em an inch and they want a mile”)

(Erick Guan) #27

Added per Merge pull request #4535 from fantasticfears/webhooks-url · discourse/discourse@3daba93 · GitHub. You can try X-Discourse-Instance. The value is your Discourse instance url including domain. If you uses subfolder feature, it would also include the subfolder name.

(Erick Guan) #28

I missed this event. I will submit the pull request.

My intention is to push as most information as possible. But a lot of people complains about it. Later I would send only the relevant model. E.g. Post webhook for only post.

As of the fields in the payload, I would eliminate some fields only used by the Ember app. The query language mentioned by @Lapinot might be better in a plugin.

@burke Badge Event is on the way. I will need some time for testing.

(Jack Zampolin) #29

Is there any documentation on the Payload format? I would like to write my own client and that documentation would make getting started way easier.


I realised I probably posted on the wrong post before -

on the user creation / update is it possibly to get the email address added into the payload? As was surprised to see this is missing.

Also I have noticed that it only seems to be sending out users that have updated their profile rather than new ones registered. For example I sent an invite to an email, registered via the invite of which auto approves the user but is not showing up in the list having been sent only the ones that I have updated.

User Event
When a user is created, approved or updated.

Problems with the new-user webhook
(Burke) #31

@fantasticfears, any closer with Badge events? Anything we could do to help? Thanks!

Still salivating about how Badge Event webhooks could revolutionize spam filtering for our community by allowing Discourse badge assignments to manipulate LDAP entries. :nerd:

(Erick Guan) #32

@jackzampolin The payload is almost the same as the Discourse web application gets. The generic format is like this:

  "user": {
    // user payload

You can read the payload examples in the webhook event page.

@mikechristopher Thanks for mention that. I included this within the submitted pull request.

@burke The team will focus on some important event types. Once the pull request which allows easy customization is ready, I’ll write a documentation to show how to add some types on your own.

How to get email notifications when new users have signed up?
(Jack Zampolin) #33

@fantasticfears By the webhook event page do you mean this topic: Webhook for Discourse events

It would be nice to have exact JSON examples for each event type. That way developing clients is very easy.

(Erick Guan) #34

As the recent change to webhooks (many thanks to @tgxworld for the help), the serialization payload includes only relevant object. i.e. Payload for topic event type includes only topic.

Please start a new topic for any other webhook feature requests and bug report.

(Alan Tan) closed #35