Webhooks feedback

Actually I wasn’t really clear, I meant “like edit-post but for the first post of every topic”. My usecase for this one is to extract the first posts of some specially formatted topics to publish them on a static generated website (and stay in sync if it gets updated):

I get it. Now you would have to use Post Event and check its post_number.

As of customized payload, I am not sure it’s worth it. A filter is harder to learn than just throw others away. If there is a way to get edit-post for first post, I guess it doesn’t matter how large the payload it is as it happens less than you notice.

Yeah, I do agree, but just filtering may be really handy: if I set up the post webhook here on meta, I will maybe get a call every couple minutes (maybe more I don’t know), a lot more than say the edition on the first post of a topic starting with [news]. And this query language isn’t complicated, for this example the filter query would be something like:

{'post': {'post_number': 1, 'topic_title': {'$regex':'^\[news\]'}}}

And here is a sample implementation in python as bonus :snake: (I’ll try to do it in ruby to make a pr or something).

https://gist.github.com/Lapin0t/3862ada8bb5f0bf58e101096a6e06c81

1 Like

Ok webhooks feature has been merged into core :slight_smile:

5 Likes

Is there a webhook for “new user account created and email was just confirmed?” If not, can we make sure we add one?

1 Like

Not yet. Right now webhooks are only triggered for create/destroy/edit events on topics and posts.

@fantasticfears can you have a look to see if it is easy to add one? :slight_smile:

Some feedback :slight_smile:

Events page for webhook

  1. Is it possible to have message bus publish the events so that we get live updates instead of having to refresh the page?
  2. We should probably add headers to explain what each column mean.
  3. The ping button needs to be disabled until the previous ping event completes. Otherwise, I can spam pings at the hook.
4 Likes

Another thing I noticed is that there is no differentiation between creation, revision and deletion in the web hook header.

Sure, I will start working on them.

3 Likes

I have a question, the webhooks say you can’t have localhost events, I am trying it on http://127.0.0.1:1245, and it says this message

[quote]It seems you are trying to set up the webhook to a local url. Event
delivered to a local address may cause side-effect or unexpected
behaviours. Continue?[/quote]

Is it possible to allow that? I am trying to setup a webhook to a local nodejs server for a project, but the requests don’t appear to go through to localhost, is there a way to do so? I don’t want to have to write a plugin for this.

Yep, that’s what the warning was talking about.

You need to give your server’s external IP, or the docker link’s host IP (172.[1,2,3]*.*.*) as the webhook destination - I’d recommend the external IP.

Of course, then you need to watch for other people sending garbage to the server…

4 Likes

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!

1 Like

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.

3 Likes

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

5 Likes

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.

1 Like

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?

1 Like

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.

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.

2 Likes

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.

4 Likes

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)